Re: kernel guide to space

[Denis Vlasenko]

> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/