From: Larry McVoy <lm@bitmover.com>
To: Christoph Hellwig <hch@infradead.org>,
Chris Heath <chris@heathens.co.nz>,
linux-kernel@vger.kernel.org
Subject: coding style (was Re: [PATCH][2.5] UTF-8 support in console)
Date: Sat, 31 May 2003 07:43:23 -0700 [thread overview]
Message-ID: <20030531144323.GA22810@work.bitmover.com> (raw)
In-Reply-To: <20030531152133.A32144@infradead.org>
> Please linewrap after 80 chars.
Amen to that.
> + if (!q) {
>
> Kill the blank line above.
>
> + if (!q) return;
>
> Two lines again.
A couple of comments: in the BK source tree, we've diverged from the Linux
coding style a bit (maybe a lot, Linus has read the source, ask him).
One thing is
unless (p) {
....
}
instead of
if (!p) {
....
}
It's just a
#define unless(x) if (!(x))
but it makes some code read quite a bit easier. I'm a stickler for not using
2 lines where one will do, i.e.,
FILE *f;
...
unless (f = fopen(file, "r")) {
error handling;
return (-1);
}
You hiccup the first time you see it, then you can read it, then you
start using it. Yeah, I know, I'm using the value of an assignment in
a conditional, trust me, it works fine.
One other one is the
if (!q) return;
Chris said two lines, we don't do it that way. The coding style we use is
a) one line is fine for a single statement.
b) in all other cases there are curly braces
unless (q) return; /* OK */
unless (q) { /* also OK */
return;
}
unless (q)
return; /* not OK, no "}" */
The point of this style is twofold: save a line when the thing you are
doing is a singe statement, and make it easier for your eyes (or my
tired old eyes) to run over the code. If you see indentation you know
it is a block and there will be a closing } without exception.
It keeps the line counts about 10% smaller or so in our source base.
If you are looking for bragging rights about how big your stuff is that
might be bad but I like it because I can read more code in a window.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2003-05-31 14:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-31 14:10 [PATCH][2.5] UTF-8 support in console Chris Heath
2003-05-31 14:21 ` Christoph Hellwig
2003-05-31 14:43 ` Larry McVoy [this message]
2003-05-31 15:01 ` coding style (was Re: [PATCH][2.5] UTF-8 support in console) Dave Jones
2003-05-31 15:39 ` Larry McVoy
2003-05-31 17:14 ` Steven Cole
2003-05-31 17:56 ` viro
2003-05-31 19:37 ` [PATCH][2.5] UTF-8 support in console Chris Heath
-- strict thread matches above, loose matches on Subject: below --
2003-05-31 16:06 coding style (was Re: [PATCH][2.5] UTF-8 support in console) john
2003-06-01 4:41 ` Matt Mackall
2003-06-01 5:18 ` Randy.Dunlap
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=20030531144323.GA22810@work.bitmover.com \
--to=lm@bitmover.com \
--cc=chris@heathens.co.nz \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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