> 3c. * in types
> Leave space between name and * in types.
> Multiple * dont need additional space between them.
>
> struct foo **bar;
unless you declare a fuction:
int*
function_style_for_easy_grep(...)
{
...
}
I like this style because I can grep for ^function_style_for_easy_grep
and quickly find function def.
int
*function_style_for_easy_grep(...) ..
would make it harder.
> 3e. sizeof
> space after the operator
> sizeof a
I use sizeof(a) always (both for sizeof(type) and sizeof(expr)).
> 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);
What's wrong with if(expr) ? Rationale?
> 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)) {
> }
Avoid this. If needed, use a temporary. Save a few brain cells of poor reader.
> 6. One-line statement does not need a {} block, so dont put it into one
> if (foo)
> bar;
Disagree. Common case of hard-to-notice bug:
if(foo)
bar()
...after some time code evolves into:
if(foo)
/*
* Wee need to barify it, or else pagecache gets foobar'ed
*/
bar();
...after some more time:
if(foo)
/*
* Wee need to barify it, or else pagecache gets foobar'ed.
* Also we need to bazify it.
*/
bar();
baz();
Thus we may be better to slighty encourage use of {}s even if they are
not needed:
if(foo) {
bar();
}
> 9a. Integer types
> Use unsigned long if you have to fit a pointer into integer.
This is a porting nightmare waiting to happen.
Why dont we have ptr_t instead?
> long long is at least 64 bit wide on all platforms.
hugeint or hugeint_t
And also irqflags_t for spinlock_irqsave(&lock, flags),
jiffies_t for jiffies.
> 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);
? did you mean struct foo (*foo_bar_handler)(... or struct foo*
foo_bar_handler(...
--
vda
-
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/
