All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.