Messages in this thread |  | | | Date | Fri, 29 Jul 2005 09:40:14 +0200 (MEST) | | From | Jan Engelhardt <> | | Subject | Re: kernel guide to space (updated) |
| |
>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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |