[lkml]   [2005]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel guide to space (updated)

>3e. sizeof
> space after the operator
> no space if the operand is in barces


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

() parentheses (short form: parens)
[] square brackets
{} braces
<> dunno their name :p

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

Why this? if(a) {} is not any worse than if (a). I would make this an option.

>3j. return
> space between return and following expression,
> even if the operand is in barces


> return (a);

No unnecessary parentheses:

return (3 + 7) * 5;
return 1;

instead of

return ((3 + 7) * 5);
return (1);

>3k. 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();

Would it be reasonable to say that the first column can be a space?
Some editors (e.g. joe) list the function in some status bar and do that based
on the fact that all C code in a function is indented, and only the function
header is non-indented. Putting a label statement fools the algorithm.
joe-bug or option for freedom?

>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;
> }

switch(foo) {
default: {
int somevar = dosomething;

What now? You've got two }} after another.

Jan Engelhardt
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-29 09:46    [W:0.113 / U:9.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site