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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.