From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 01/10] ftgmac100: Upgrade to NETIF_F_HW_CSUM
Date: Tue, 11 Apr 2017 23:50:10 +1000 [thread overview]
Message-ID: <1491918610.7236.12.camel@kernel.crashing.org> (raw)
In-Reply-To: <1491909225.4166.248.camel@kernel.crashing.org>
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.
next prev parent reply other threads:[~2017-04-11 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 1:04 [PATCH 00/10] ftgmac100: Rework batch 4 - Misc Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 01/10] ftgmac100: Upgrade to NETIF_F_HW_CSUM Benjamin Herrenschmidt
2017-04-11 10:57 ` Sergei Shtylyov
2017-04-11 11:13 ` Benjamin Herrenschmidt
2017-04-11 13:50 ` Benjamin Herrenschmidt [this message]
2017-04-11 15:27 ` David Miller
2017-04-11 22:06 ` Benjamin Herrenschmidt
2017-04-11 23:36 ` Benjamin Herrenschmidt
2017-04-12 0:03 ` David Miller
2017-04-12 0:08 ` Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 02/10] ftgmac100: Use device "compatible" property, not machine Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 03/10] ftgmac100: Disable HW checksum generation on AST2400, enable on others Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 04/10] ftgmac100: Set netdev->hw_features Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 05/10] ftgmac100: Rename ftgmac100_set_mac to ftgmac100_write_mac_addr Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 06/10] ftgmac100: Rename ftgmac100_setup_mac to ftgmac100_initial_mac Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 07/10] ftgmac100: Open code remaining register writes Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 08/10] ftgmac100: Add more register inits in ftgmac100_init_hw() Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 09/10] ftgmac100: Make ring sizes configurable via ethtool Benjamin Herrenschmidt
2017-04-11 1:04 ` [PATCH 10/10] ftgmac100: Set default ring sizes to 128 entries Benjamin Herrenschmidt
2017-04-11 1:08 ` [PATCH 00/10] ftgmac100: Rework batch 4 - Misc Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1491918610.7236.12.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=netdev@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).