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
next prev 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®