linux-kernel - Re: [Ksummit-discuss] checkkpatch (in)sanity ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2016 23:07:59 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     ksummit-discuss@...ts.linuxfoundation.org
Cc:     Joe Perches <joe@...ches.com>, "Luck, Tony" <tony.luck@...el.com>,
        "Levin, Alexander" <alexander.levin@...izon.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sasha Levin <levinsasha928@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Monday 29 August 2016, 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.

My preferred personal guideline for the maximum indentation is
the area that a function takes up in the editor. It's sometimes
ok to have really long functions (hundreds of lines), but only
with one or two levels of indentation. It's also sometimes ok
to have five or six levels of intendation, but only if the
function is really short and you can see immediately how
it works.

Having a long function with multiple nested loops and conditions
is almost always a problem for readability, and we should be
able to detect this programatically if we want to.

There are more accurate ways to tell if you are getting
too complex (e.g. CONFIG_GCC_PLUGIN_CYC_COMPLEXITY), but that
becomes harder to warn about.

	Arnd