mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@mellanox.co.il>
To: linux-kernel@vger.kernel.org
Subject: kernel guide to space
Date: Mon, 11 Jul 2005 17:56:16 +0300	[thread overview]
Message-ID: <20050711145616.GA22936@mellanox.co.il> (raw)

Hi!
I've been tasked with edicating some new hires on linux kernel coding style.
While we have Documentation/CodingStyle, it skips detail that is supposed to
be learned by example.

Since I've been burned by this a couple of times myself till I learned,
I've put together a short list of rules complementing Documentation/CodingStyle.
This list is attached, below.

Please cc me directly with comments, if any.

Thanks,
MST

---

kernel guide to space AKA a boring list of rules
http://www.mellanox.com/mst/boring.txt

This text deals mostly with whitespace issues, hence the name.

Whitespace -- In computer science, a whitespace (or a whitespace character) is
any character which does not display itself but does take up space.
	From Wikipedia, the free encyclopedia.

1. Read Documentation/CodingStyle. Yes, it applies to you.
   When working on a specific driver/subsystem, try to follow
   the style of the surrounding codebase.

2. The last character on a line is never a whitespace
		Get a decent editor and don't leave whitespace at the end of
		lines.
			Documentation/CodingStyle

Whitespace issues:

3. Space rules for C

3a. Binary operators
	+ - / * %
	== !=  > < >= <= && || 
	& | ^ << >> 
	= *= /= %= += -= <<= >>= &= ^= |=

	spaces around the operator
	a + b

3b. Unary operators
	! ~
	+ - *
	&

	no space between operator and operand
	*a

3c. * in types
	Leave space between name and * in types.
	Multiple * dont need additional space between them.

	struct foo **bar;

3d. Conditional
	?:
	spaces around both ? and :
	a ? b : c

3e. sizeof
	space after the operator
	sizeof a

3f. Braces etc
	() [] -> .

	no space around any of these (but see 3h)
	foo(bar)

3g. Comma
	,
	space after comma, no space before comma
	foo, bar

3h. Semicolon
	;
	no space before semicolon
	foo;

3i. if/else/do/while/for/switch
	space between if/else/do/while and following/preceeding
	statements/expressions, if any:

	if (a) {
	} else {
	}

	do {
	} while (b);

3j. Labels
	goto and case labels should have a line of their own (possibly
	with a comment).
	No space before colon in labels.

int foobar()
{
	...
foolabel: /* short comment */
	foo();
}

4. Indentation rules for C
	Use tabs, not spaces, for indentation. Tabs should be 8 characters wide.

4a. Labels
	case labels should be indented same as the switch statement.
	statements occurring after a case label are indented by one level.

	switch (foo) {
	case foo:
		bar();
	default:
		break;
	}

4b. Global scope
	Functions, type definitions/declarations, defines, global
	variables etc are global scope. Start them at the first
	character in a line (indent level 0).

static struct foo *foo_bar(struct foo *first, struct bar *second,
			   struct foobar* thirsd);

4c. Breaking long lines
		Descendants are always substantially shorter than the parent
		and are placed substantially to the right.
			Documentation/CodingStyle

	Descendant must be indented at least to the level of the innermost
	compound expression in the parent. All descendants at the same level
	are indented the same.
	if (foobar(.................................) + barbar * foobar(bar +
				     					foo *
									oof)) {
	}

5. Blank lines
	One blank line between functions.

void foo()
{
}

/* comment */
void bar()
{
}

	No more than one blank line in a row.
	Last (or first) line in a file is never blank.

Non-whitespace issues:

6. One-line statement does not need a {} block, so dont put it into one
	if (foo)
		bar;

7. Comments
	Dont use C99 // comments.

8. Return codes
	Functions that return success/failure status, should use 0 for success,
	a negative value for failure.
	Error codes are in linux/errno.h .

	if (do_something()) {
		handle_error();
		return -EINVAL;
	}

	Functions that test a condition return 1 if condition is satisfied,
	0 if its not.

	if (is_condition())
		condition_true();

9. Data types
	Standard linux types are in linux/types.h .
	See also Linux Device Drivers, Third Edition,
	Chapter 11: Data Types in the Kernel.  http://lwn.net/images/pdf/LDD3/

9a. Integer types
	int is the default integer type.
	Use unsigned type if you perform bit operations (<<,>>,&,|,~).
	Use unsigned long if you have to fit a pointer into integer.
	long long is at least 64 bit wide on all platforms.
	char is for ASCII characters and strings.
	Use u8,u16,u32,u64 if you need an integer of a specific size.

9b. typedef
	Using typedefs to hide the data type is generally discouraged.
	typedefs to function types are ok, since these can get very long.

typedef struct foo *(foo_bar_handler)(struct foo *first, struct bar *second,
				      struct foobar* thirsd);

Editor configuration:

9. The following is helpful with VIM
	set cinoptions=(0:0

Michael S. Tsirkin

-- 
MST

             reply	other threads:[~2005-07-11 15:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 14:56 Michael S. Tsirkin [this message]
2005-07-11 15:34 ` Sander
2005-07-12  6:52   ` Denis Vlasenko
2005-07-12 11:55     ` Patrick McHardy
2005-07-12 12:17       ` Richard B. Johnson
2005-07-13  6:58         ` Paul Jackson
2005-07-13 17:22           ` Lee Revell
2005-07-13 17:52             ` Paul Jackson
2005-07-13 23:38             ` Marc Singer
2005-07-11 15:44 ` Dmitry Torokhov
2005-07-11 17:19   ` Ingo Oeser
2005-07-12  7:12 ` Denis Vlasenko
2005-07-12 11:36   ` Domen Puncer
2005-07-13  7:09 ` Paul Jackson
2005-07-20 12:59 ` Jesper Juhl
2005-07-20 13:07   ` Michael S. Tsirkin
2005-07-20 21:05   ` Paul Jackson
2005-07-20 22:37   ` Krzysztof Halasa
2005-07-22 17:12     ` Patrick Draper
2005-07-22 17:51       ` Jesper Juhl
2005-07-22 19:21       ` Sam Ravnborg
2005-07-22 20:28         ` Jesper Juhl
2005-07-21  0:20   ` Horst von Brand
     [not found] <4p851-3Tl-11@gated-at.bofh.it>
     [not found] ` <4p8HK-4he-19@gated-at.bofh.it>
     [not found]   ` <4pmUD-7gx-37@gated-at.bofh.it>
2005-07-12 19:36     ` Bodo Eggert
2005-07-13  5:46       ` Denis Vlasenko
2005-07-14  1:12 linux
2005-07-20  3:41 ` Kyle Moffett
2005-07-20  7:52   ` Jan Engelhardt
2005-07-21  0:45     ` Paul Jackson
2005-07-21  6:22       ` Jan Engelhardt
2005-07-21 16:57       ` Kyle Moffett
2005-07-21 18:42         ` Jesper Juhl
2005-07-21 19:37           ` linux-os (Dick Johnson)
2005-07-21 20:11             ` Jesper Juhl
2005-07-22  1:32               ` Jesper Juhl
2005-07-23  1:30                 ` Jesper Juhl
2005-07-22  2:29             ` Miles Bader
2005-07-22  3:47               ` Paul Jackson
     [not found] <4q0yr-4YQ-3@gated-at.bofh.it>
     [not found] ` <4sdKS-7Ko-9@gated-at.bofh.it>
     [not found]   ` <4shEU-25p-5@gated-at.bofh.it>
2005-07-20 17:42     ` Bodo Eggert

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=20050711145616.GA22936@mellanox.co.il \
    --to=mst@mellanox.co.il \
    --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

all inboxes | Powered by JetHome®