mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: "Michael S. Tsirkin" <mst@mellanox.co.il>, linux-kernel@vger.kernel.org
Subject: Re: kernel guide to space
Date: Tue, 12 Jul 2005 10:12:39 +0300	[thread overview]
Message-ID: <200507121012.39215.vda@ilport.com.ua> (raw)
In-Reply-To: <20050711145616.GA22936@mellanox.co.il>

> 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


  parent reply	other threads:[~2005-07-12  7:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 14:56 Michael S. Tsirkin
2005-07-11 15:34 ` Sander
2005-07-12  6:52   ` Denis Vlasenko
2005-07-12 11:55     ` Patrick McHardy
2005-07-12 12:17       ` Richard B. Johnson
2005-07-13  6:58         ` Paul Jackson
2005-07-13 17:22           ` Lee Revell
2005-07-13 17:52             ` Paul Jackson
2005-07-13 23:38             ` Marc Singer
2005-07-11 15:44 ` Dmitry Torokhov
2005-07-11 17:19   ` Ingo Oeser
2005-07-12  7:12 ` Denis Vlasenko [this message]
2005-07-12 11:36   ` Domen Puncer
2005-07-13  7:09 ` Paul Jackson
2005-07-20 12:59 ` Jesper Juhl
2005-07-20 13:07   ` Michael S. Tsirkin
2005-07-20 21:05   ` Paul Jackson
2005-07-20 22:37   ` Krzysztof Halasa
2005-07-22 17:12     ` Patrick Draper
2005-07-22 17:51       ` Jesper Juhl
2005-07-22 19:21       ` Sam Ravnborg
2005-07-22 20:28         ` Jesper Juhl
2005-07-21  0:20   ` Horst von Brand
     [not found] <4p851-3Tl-11@gated-at.bofh.it>
     [not found] ` <4p8HK-4he-19@gated-at.bofh.it>
     [not found]   ` <4pmUD-7gx-37@gated-at.bofh.it>
2005-07-12 19:36     ` Bodo Eggert
2005-07-13  5:46       ` Denis Vlasenko
2005-07-14  1:12 linux
2005-07-20  3:41 ` Kyle Moffett
2005-07-20  7:52   ` Jan Engelhardt
2005-07-21  0:45     ` Paul Jackson
2005-07-21  6:22       ` Jan Engelhardt
2005-07-21 16:57       ` Kyle Moffett
2005-07-21 18:42         ` Jesper Juhl
2005-07-21 19:37           ` linux-os (Dick Johnson)
2005-07-21 20:11             ` Jesper Juhl
2005-07-22  1:32               ` Jesper Juhl
2005-07-23  1:30                 ` Jesper Juhl
2005-07-22  2:29             ` Miles Bader
2005-07-22  3:47               ` Paul Jackson
     [not found] <4q0yr-4YQ-3@gated-at.bofh.it>
     [not found] ` <4sdKS-7Ko-9@gated-at.bofh.it>
     [not found]   ` <4shEU-25p-5@gated-at.bofh.it>
2005-07-20 17:42     ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507121012.39215.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@mellanox.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®