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
next 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®