Re: CodingStyle: start flamewar about use of braces

["Satyam Sharma" <satyam.sharma@gmail.com>]

On 5/9/07, Jeff Garzik <jeff@garzik.org> wrote:
> Randy Dunlap wrote:
> > On Tue, 8 May 2007 19:03:10 GMT Linux Kernel Mailing List wrote:
> >
> >> Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e659ba4a0d2d471c0d73590f78e1a1b5a1eede48
> >> Commit:     e659ba4a0d2d471c0d73590f78e1a1b5a1eede48
> >> Parent:     28be5abb400e5e082f5225105fdc69337ec0c0b4
> >> Author:     Oliver Neukum <oliver@neukum.org>
> >> AuthorDate: Tue May 8 00:30:34 2007 -0700
> >> Committer:  Linus Torvalds <torvalds@woody.linux-foundation.org>
> >> CommitDate: Tue May 8 11:15:12 2007 -0700
> >>
> >>     CodingStyle: start flamewar about use of braces
> >
> > It worked somewhat.  We never did reach any kind of
> > concensus about this....
> >
> >
> >>     Signed-off-by: Oliver Neukum <oneukum@suse.de>
> >>     Cc: Tilman Schmidt <tilman@imap.cc>
> >>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >> ---
> >>  Documentation/CodingStyle |   15 +++++++++++++++
> >>  1 files changed, 15 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> >> index 9069189..e7f5fc6 100644
> >> --- a/Documentation/CodingStyle
> >> +++ b/Documentation/CodingStyle
> >> @@ -160,6 +160,21 @@ supply of new-lines on your screen is not a renewable resource (think
> >>  25-line terminal screens here), you have more empty lines to put
> >>  comments on.
> >>
> >> +Do not unnecessarily use braces where a single statement will do.
> >> +
> >> +if (condition)
> >> +    action();
> >> +
> >> +This does not apply if one branch of a conditional statement is a single
> >> +statement. Use braces in both branches.
> >> +
> >> +if (condition) {
> >> +    do_this();
> >> +    do_that();
> >> +} else {
> >> +    otherwise();
> >> +}
>
> If anyone tries to add braces to my code's 'else' statements where they
> are not required, that patch will get NAK'd in a heartbeat.

Yes. This patch shouldn't go in. There's no ambiguity in
Documentation/CodingStyle that it fixes anyway, only *imposes* a
"style", which:

(1) there is no consensus about *at all*, and

(2) blatantly goes against _all_ similar examples in K&R.

It's quite funny to worship them as "prophets" and adopt their style
for some stuff (with a simple "Rationale: K&R.") one instant and then
suggest a style completely opposite to theirs one screenful later in
the same file.