From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932485AbcH2TIX (ORCPT ); Mon, 29 Aug 2016 15:08:23 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:42535 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932239AbcH2TIV (ORCPT ); Mon, 29 Aug 2016 15:08:21 -0400 Date: Mon, 29 Aug 2016 12:08:16 -0700 From: Josh Triplett To: Joe Perches Cc: "Luck, Tony" , "Levin, Alexander" , Greg KH , Sasha Levin , "ksummit-discuss@lists.linuxfoundation.org" , LKML Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ? Message-ID: <20160829190816.GA27600@cloud> References: <1472330452.26978.23.camel@perches.com> <20160828005636.GB19088@sasha-lappy> <1472348579.26978.47.camel@perches.com> <20160828023807.GC19088@sasha-lappy> <1472404557.26978.84.camel@perches.com> <3908561D78D1C84285E8C5FCA982C28F3A1B3222@ORSMSX114.amr.corp.intel.com> <1472493700.3425.67.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1472493700.3425.67.camel@perches.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2016 at 11:01:40AM -0700, Joe Perches wrote: > On Mon, 2016-08-29 at 17:46 +0000, Luck, Tony wrote: > > > > > > 80 columns is simply silly when dealing with either > > > long identifiers or many levels of indentation. > > > > > > One thing that 80 column limit does do is encourage > > > shorter identifiers and fewer levels of indentation. > > > > > > Generally, both of those are good things. > > I think the main complaint with the limit is that people fix it by simply > > breaking the long line, which often makes for less readable code. > > > > Perhaps there would be less pushback on this if checkpatch also > > complained about clumsily broken long lines and offered the advice > > to restructure the code with helper functions etc. to avoid deep > > indentation? > > It suggests that already for 6+ leading tabs, but some more > intelligence for nominally ugly added line breaks would > definitely help. > > Using longish simple identifiers or multiple dereferences > can make the line breaks at 80 columns silly. > > Simple things like: > > if (longish_identifier != AN_EVEN_LONGER_DEFINED_CONSTANT_VALUE) > and > if (some_pointer->member[index].another_member >> shift_constant) > > shouldn't really ever be broken into multiple lines, Agreed. Honestly, I almost never see a line that should break solely based on length. Almost any line that makes sense to break at a given point would make sense to break at that point even with a target line length of 200. For instance: if (an_interesting_function(x) == TARGET_VALUE_FOR_X || an_interesting_function(y) == TARGET_VALUE_FOR_Y) { That line break makes sense whether you want to break lines at 80 characters, 100, or 800. (You could argue about before-or-after-operator, or about line alignment.) In almost no circumstances would you want to also break around the '==', even though that second line takes up 82 characters.