>3e. sizeof
> space after the operator
> no space if the operand is in barces
braces
>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
parentheses
> 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;
break;
}
}
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
