netdev - Re: [PATCH 01/10] ftgmac100: Upgrade to NETIF_F_HW

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 11 Apr 2017 23:50:10 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH 01/10] ftgmac100: Upgrade to NETIF_F_HW_CSUM

On Tue, 2017-04-11 at 21:13 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-04-11 at 13:57 +0300, Sergei Shtylyov wrote:
> >     Need {} here as well since the 1st branch has it -- see 
> > Documentation/process/coding-style.rst (the end of the section 3).
> 
> Adding {} in that specific statements just makes things more
> cluttered and less readable.
> 
> I can find a ton of examples of 
> 
> 	if (...) {
> 		multi lines
> 		...
> 	} else if (...)
> 		single_line()
> 
> In existing kernel code.
> 
> I'll fix it in a next spin if Dave wants it that way but otherwise
> I'm keen to leave it as it is.

I actually took the time to read the coding-style.txt statement,
and I would argue that it is about

	if (...) {
		...
	} else {
		...
	}

Which is a different can of worms. I tend to agree that the else by
itself followed by a single tabulated statement is a bit "odd" and
I tend to use braces in that case as well.

However the "} else if (...)" case is subtly different and from a code
clarity point of view I prefer what I wrote.

This isn't an accident, I specifically wrote that statement that way
because I preferred how the code looked like that way.

This tend to be my problem with coding style rules (and people who
comment on patches solely on coding style issues, especially so
marginal ones ;-) ... this needs to be applied along with a bit of
common sense and taste.

Those rules should be "general guidelines" not absolute laws. A
specific piece of code might benefit from violating some of them
occasionally for all sort of reasons provided the end result is both
clear and more concise for example.

Anyway, way too much internet bandwidth wasted today on that subject.

Dave, just let me know how you want it to look like :-)

Cheers,
Ben.