From: Jesper Juhl <jesper.juhl@gmail.com>
To: "Michael S. Tsirkin" <mst@mellanox.co.il>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel guide to space
Date: Wed, 20 Jul 2005 14:59:51 +0200 [thread overview]
Message-ID: <9a87484905072005596f2c2b51@mail.gmail.com> (raw)
In-Reply-To: <20050711145616.GA22936@mellanox.co.il>
On 7/11/05, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
>
[snip]
> kernel guide to space AKA a boring list of rules
> http://www.mellanox.com/mst/boring.txt
>
[snip]
>
> 3c. * in types
> Leave space between name and * in types.
> Multiple * dont need additional space between them.
>
> struct foo **bar;
>
Don't put spaces between `*' and the name when declaring variables,
even if it's not a double pointer. int * foo; is ugly. Common
convention is int *foo;
> 3e. sizeof
> space after the operator
> sizeof a
>
I don't think that's a hard rule, there's plenty of code that does
"sizeof(type)" and not "sizeof (type)", and whitespace cleanup
patches I've done that change "sizeof (type)" into "sizeof(type)" have
generally been accepted.
[snip]
>
> 4. Indentation rules for C
> Use tabs, not spaces, for indentation. Tabs should be 8 characters wide.
>
A tab is a tab is a tab, how it's displayed is up to the editor
showing the file.
[snip]
>
> static struct foo *foo_bar(struct foo *first, struct bar *second,
> struct foobar* thirsd);
>
In this example you are not consistently placing your *'s, "struct foo
*first" vs "struct foobar* thirsd". Common practice is "struct foo
*first".
[snip]
>
> No more than one blank line in a row.
> Last (or first) line in a file is never blank.
>
Files should end with a newline. gcc will even warn (with -pedantic)
if this is not so.
"line<nl>
line"
is wrong,
"line<nl>
line<nl>
"
is right.
> Non-whitespace issues:
>
> 6. One-line statement does not need a {} block, so dont put it into one
> if (foo)
> bar;
>
Not always so, if `bar' is a macro adding {} may be safer. Also
sometimes adding {} improves readability, which is important.
> 7. Comments
> Dont use C99 // comments.
>
s/Dont/Don't/
> 9a. Integer types
> int is the default integer type.
> Use unsigned type if you perform bit operations (<<,>>,&,|,~).
> Use unsigned long if you have to fit a pointer into integer.
> long long is at least 64 bit wide on all platforms.
> char is for ASCII characters and strings.
> Use u8,u16,u32,u64 if you need an integer of a specific size.
u8,s8,u16,s16,u32,s32,u64,s64
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
next prev parent reply other threads:[~2005-07-20 13:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 14:56 kernel guide to space 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
2005-07-12 11:36 ` Domen Puncer
2005-07-13 7:09 ` Paul Jackson
2005-07-20 12:59 ` Jesper Juhl [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=9a87484905072005596f2c2b51@mail.gmail.com \
--to=jesper.juhl@gmail.com \
--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