From: Timothy Miller <miller@techsource.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "P. Benie" <pjb1008@eng.cam.ac.uk>,
Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Coding standards. (Was: Re: [PATCH] [2.5] Non-blocking write can block)
Date: Wed, 04 Jun 2003 11:21:41 -0400 [thread overview]
Message-ID: <3EDE0E85.7090601@techsource.com> (raw)
In-Reply-To: 20030604065336.A7755@infradead.org
Christoph Hellwig wrote:
> On Wed, Jun 04, 2003 at 01:58:02AM +0100, P. Benie wrote:
>
>>- if (down_interruptible(&tty->atomic_write)) {
>>- return -ERESTARTSYS;
>>+ if (file->f_flags & O_NONBLOCK) {
>>+ if (down_trylock(&tty->atomic_write))
>>+ return -EAGAIN;
>>+ }
>>+ else {
>
>
> The else should be on the same line as the closing brace, else
> the patch looks fine.
I am in general agreement with those who feel we should have a common
standard for code formatting. There are particular places where it's
VERY important to maximize consistency and readability, such as function
headers.
But when do standards turn into nitpicks?
I personally always write else as you suggest, "} else {", but the way
the other fellow did it does not in any way hurt readability for me.
Yes, it does irritate me sometimes when people put the braces and else
on three different lines, but mostly because it reduces the amount of
code I can see at one time. But even then, it doesn't make it any less
readable to me.
I can see patches getting rejected because they violate function header
standards. That would make sense to me. But if the above patch were to
be rejected on the basis of the "else", I would be hard pressed to see
that as a valid justification.
Perhaps it would be good to have an explanation for the relative
importance of placing braces and else on the same line as compared to
other formatting standards.
next prev parent reply other threads:[~2003-06-04 14:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 0:58 [PATCH] [2.5] Non-blocking write can block P. Benie
2003-06-04 5:53 ` Christoph Hellwig
2003-06-04 14:35 ` Linus Torvalds
2003-06-04 14:58 ` P. Benie
2003-06-04 16:47 ` Alan Cox
2003-06-04 17:57 ` Linus Torvalds
2003-06-04 19:46 ` P. Benie
2003-06-04 19:56 ` Linus Torvalds
2003-06-04 20:48 ` P. Benie
2003-06-11 0:19 ` Robert White
2003-06-04 20:43 ` Hua Zhong
2003-06-04 23:42 ` Russell King
2003-06-04 23:47 ` Davide Libenzi
2003-06-04 21:29 ` Alan Cox
2003-06-04 17:14 ` Hua Zhong
2003-06-04 17:41 ` Linus Torvalds
2003-06-04 18:44 ` Hua Zhong
2003-06-04 18:47 ` P. Benie
2003-06-04 19:23 ` P. Benie
2003-06-04 19:20 ` Linus Torvalds
2003-06-04 17:53 ` Mike Dresser
2003-06-04 15:21 ` Timothy Miller [this message]
2003-06-07 0:12 ` Coding standards. (Was: Re: [PATCH] [2.5] Non-blocking write can block) Greg KH
2003-06-07 0:59 ` Alex Goddard
2003-06-09 16:24 ` Timothy Miller
2003-06-09 16:39 ` Jörn Engel
2003-06-09 17:15 ` Davide Libenzi
2003-06-09 17:33 ` Eli Carter
2003-06-09 17:49 ` Richard B. Johnson
2003-06-09 18:07 ` Davide Libenzi
2003-06-09 18:22 ` Jörn Engel
2003-06-09 18:55 ` Timothy Miller
2003-06-09 18:58 ` Davide Libenzi
2003-06-09 21:35 ` David Schwartz
2003-06-09 22:55 ` Davide Libenzi
2003-06-09 23:21 ` Nigel Cunningham
2003-06-09 21:54 ` Jörn Engel
2003-06-10 18:17 ` Jesse Pollard
2003-06-10 18:41 ` Davide Libenzi
2003-06-10 18:14 ` Jesse Pollard
2003-06-09 23:50 ` James Stevenson
2003-06-09 18:44 ` Timothy Miller
2003-06-09 22:00 ` Jörn Engel
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=3EDE0E85.7090601@techsource.com \
--to=miller@techsource.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pjb1008@eng.cam.ac.uk \
--cc=torvalds@transmeta.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