Jan Engelhardt <[EMAIL PROTECTED]> writes:
>>3i. if/else/do/while/for/switch
>> space between if/else/do/while and following/preceeding
>> statements/expressions, if any
>
> Why this? if(a) {} is not any worse than if (a).
Well it's harder to read (because it makes control constructs loo
>> >Ehrm, yes, I'm perfectly aware of that. Note the "for consistency" in
>> >that sentence. If we add an extra space in front of the labels that
>> >have an indentation level of 0, we'd better do it with the labels that
>> >have an indentation level > 0 too.
>>
>> Labels at level > 0???
>
>A ca
On Sat, Jul 30, 2005 at 01:41:55PM +0200, Jan Engelhardt wrote:
>
> >Ehrm, yes, I'm perfectly aware of that. Note the "for consistency" in
> >that sentence. If we add an extra space in front of the labels that
> >have an indentation level of 0, we'd better do it with the labels that
> >have an i
>Ehrm, yes, I'm perfectly aware of that. Note the "for consistency" in
>that sentence. If we add an extra space in front of the labels that
>have an indentation level of 0, we'd better do it with the labels that
>have an indentation level > 0 too.
Labels at level > 0???
-
To unsubscribe from
On Fri, Jul 29, 2005 at 09:40:14AM +0200, Jan Engelhardt wrote:
> >3i. if/else/do/while/for/switch
> > space between if/else/do/while and following/preceeding
> > statements/expressions, if any
>
> Why this? if(a) {} is not any worse than if (a). I would make this an option.
please no, it
On Fri, Jul 29, 2005 at 09:52:01PM +0200, Jan Engelhardt wrote:
>
> >I'd definitely call that a joe-bug. Adding extra space for no good
> >reason is just silly; for consistency we'd have to add a space for the
> >case : labels also...
>
> No, the word "case" never starts at column 1 (counting fr
>I'd definitely call that a joe-bug. Adding extra space for no good
>reason is just silly; for consistency we'd have to add a space for the
>case : labels also...
No, the word "case" never starts at column 1 (counting from 1), but at least
in column , where minimalIndent is the default indent f
On Fri, Jul 29, 2005 at 09:40:14AM +0200, Jan Engelhardt wrote:
[snip]
> Would it be reasonable to say that the first column can be a space?
> Some editors (e.g. joe) list the function in some status bar and do
> that based on the fact that all C code in a function is indented, and
> only the funct
Jan Engelhardt wrote:
>>3e. sizeof
>> space after the operator
>> no space if the operand is in barces
>>
>>
>
>braces
>
>
>
>>3f. Braces etc
>> () [] -> .
>>
>>
>
>() parentheses (short form: parens)
>[] square brackets
>{} braces
><> dunno their name :p
>
angle brackets,
>3e. sizeof
> space after the operator
> no space if the operand is in barces
braces
>3f. Braces etc
> () [] -> .
() parentheses (short form: parens)
[] square brackets
{} braces
<> dunno their name :p
>3i. if/else/do/while/for/switch
> space between if/else/do/while an
>> 9. The following is helpful with VIM
>>set cinoptions=(0:0
>>
>
>And this will highlight whitespace damage:
>
>highlight RedundantSpaces ctermbg=red guibg=red
>match RedundantSpaces /\s\+$\| \+\ze\t/
find linux -type f -print0 | xargs -0 egrep '[[:space:]]+$'
With `wc -l`, returns 13
On Thu, Jul 28, 2005 at 11:52:25AM -0400, linux-os (Dick Johnson) wrote:
>
> On Thu, 28 Jul 2005, Michael S. Tsirkin wrote:
>
> >
> > 7. Comments
> > Don't use C99 // comments.
>
> I don't think this is correct. In fact, I remember a discussion
> where // was preferred for new code.
Ick...I
On 7/28/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
>
> 9. The following is helpful with VIM
>set cinoptions=(0:0
>
And this will highlight whitespace damage:
highlight RedundantSpaces ctermbg=red guibg=red
match RedundantSpaces /\s\+$\| \+\ze\t/
--
Dmitry
-
To unsubscribe from
On Thu, 28 Jul 2005, Michael S. Tsirkin wrote:
>
> 7. Comments
> Don't use C99 // comments.
I don't think this is correct. In fact, I remember a discussion
where // was preferred for new code.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warn
On 7/22/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/21/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, 21 Jul 2005, Jesper Juhl wrote:
> > >
> > > > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > > >> O
On 7/22/05, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 22, 2005 at 12:12:12PM -0500, Patrick Draper wrote:
> > Why isn't a code formatting program used? People could write the code
> > as they like to write it, then format it automatically in a standard
> > way before it gets put into th
On 7/22/05, Patrick Draper <[EMAIL PROTECTED]> wrote:
> Why isn't a code formatting program used?
There's scripts/Lindent (which is just a wrapper around indent with
appropriate options.
>People could write the code
> as they like to write it, then format it automatically in a standard
> way b
On Fri, Jul 22, 2005 at 12:12:12PM -0500, Patrick Draper wrote:
> Why isn't a code formatting program used? People could write the code
> as they like to write it, then format it automatically in a standard
> way before it gets put into the kernel.
There is.
scripts/Lindent
But sometimes it fails
Why isn't a code formatting program used? People could write the code
as they like to write it, then format it automatically in a standard
way before it gets put into the kernel.
Patrick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
Miles wrote:
> CodingStyle is vague on the issue, though ...
Perhaps we should call it "coding_style" .
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from
"linux-os \(Dick Johnson\)" <[EMAIL PROTECTED]> writes:
> It will take probably an hour to parse:
> struct BusLogic_FetchHostAdapterLocalRAMReguest
> FetchHostAdapterLocalRAMRequest
> ^!)
Agh! My eyes!
The above names are way overdone by any measure, but is there any
consensus whe
On 7/21/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 21 Jul 2005, Jesper Juhl wrote:
> >
> > > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
> > > [...snip..
On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
>
> On Thu, 21 Jul 2005, Jesper Juhl wrote:
>
> > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
> > [...snip...]
> >> *cough* TargetStatistics[TargetID].HostAdapterResetsCom
On Thu, 21 Jul 2005, Jesper Juhl wrote:
> On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
>> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
> [...snip...]
>> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough*
>>
>> I suspect linus would be willing to accept a few cleanup
On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
[...snip...]
> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough*
>
> I suspect linus would be willing to accept a few cleanup patches for the
> BusLogic.c file. Perhaps even
On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
drivers/scsi/BusLogic.c:
%2d %5d %5d %5d%5d %5d %5d %5d %5d %5d\n",
TargetID, TargetStatistics[TargetID].CommandAbortsRequested,
TargetStatistics[TargetID].CommandAbortsAttempted, TargetStatistics
[TargetID].CommandAbortsComp
>> (Find source files, expand tab chars to their on-screen length, print if
>> >= 80, count lines)
>
>The bulk of the longest lines are in the sound and drivers subtrees.
>One example on the "high end", with 546 chars in one line:
>
>==
>drivers/scsi/BusLogic.c:
> %2d %5d %5d %5d%5d %5d %5
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> [snip]
> > 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)", a
Jan wrote:
> (Find source files, expand tab chars to their on-screen length, print if
> >= 80, count lines)
The bulk of the longest lines are in the sound and drivers subtrees.
One example on the "high end", with 546 chars in one line:
==
drivers/scsi/BusLogic.c:
%2d%5d %5d %5d%5d %
Jesper Juhl <[EMAIL PROTECTED]> writes:
> 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.
Sure, the common rul
> > 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
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> 3) If a normal line of code is more than 80 characters, one of the
>> following is probably true: you need to break the line up and use temps
>> for clarity, or your function is so big that you're tabbing over too
>> far.
>
> (Find source files, expan
Quoting r. Jesper Juhl <[EMAIL PROTECTED]>:
> > 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 practic
On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> 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 th
> 3) If a normal line of code is more than 80 characters, one of the
> following is probably true: you need to break the line up and use temps
> for clarity, or your function is so big that you're tabbing over too
> far.
(Find source files, expand tab chars to their on-screen length, print if
>
On Jul 13, 2005, at 21:12:08, [EMAIL PROTECTED] wrote:
I don't think there's a strict 80 column rule anymore. It's 2005...
Think again. There are a lot of people who use 80 column windows so
that we can see two code windows side-by-side.
Agreed. If you're having trouble with width, it's a
>> I don't think there's a strict 80 column rule anymore. It's 2005...
> Think again. There are a lot of people who use 80 column windows so
> that we can see two code windows side-by-side.
Agreed. If you're having trouble with width, it's a sign that the code
needs to be refactored.
Also, my
On Wed, Jul 13, 2005 at 01:22:04PM -0400, Lee Revell wrote:
> On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> > Dick Johnson wrote:
> > > Or just disallow tabs altogether. At Analogic we ...
> >
> > This is the Linux kernel, not Analogic.
> >
> > We use tabs for indentation. You can set
On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> Dick Johnson wrote:
> > Or just disallow tabs altogether. At Analogic we ...
>
> This is the Linux kernel, not Analogic.
>
> We use tabs for indentation. You can set the number
> of physical spaces per tab however you want in your
> editor
Lee wrote:
> I don't think there's a strict 80 column rule anymore. It's 2005...
Look back through the lkml archives. One will find repeated requests
to keep code within 80 columns. It maybe 2005, but this is the kernel.
--
I won't rest till it's the best ...
Nice work - thanks.
A couple of possible additions:
* Keep lines within 80 columns.
* Be consistent in use of tabs versus spaces. If the
rest of a file is indented using tabs, then any change
you make should be indented the same way, not with
spaces. It is easy to unknowingly introd
Dick Johnson wrote:
> Or just disallow tabs altogether. At Analogic we ...
This is the Linux kernel, not Analogic.
We use tabs for indentation. You can set the number
of physical spaces per tab however you want in your
editor, but it had better look good (and stay within
80 columns) when the res
On Tuesday 12 July 2005 22:36, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > text with 8-char tabs:
> >
> > struct s {
> > int n; /* comment */
> > unsigned int u; /* comment */
> > };
> >
> > Same text viewed with tabs set to 4-char width:
> >
>
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> text with 8-char tabs:
>
> struct s {
> int n; /* comment */
> unsigned int u; /* comment */
> };
>
> Same text viewed with tabs set to 4-char width:
>
> struct s {
> int n; /* comment */
> unsigned int u; /* comm
On Tue, 12 Jul 2005, Patrick McHardy wrote:
Denis Vlasenko wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* c
Denis Vlasenko wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Comments are not aligned anymore
On 12/07/05 10:12 +0300, Denis Vlasenko wrote:
> > 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(...)
> {
>
> 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
On Monday 11 July 2005 18:34, Sander wrote:
> Michael S. Tsirkin wrote (ao):
> > Use tabs, not spaces, for indentation. Tabs should be 8
> > characters wide.
>
> A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
> any amount of characters, right?
text with 8-char tab
On Monday 11 July 2005 17:44, Dmitry Torokhov wrote:
> >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(
Hi,
On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> 3e. sizeof
>space after the operator
>sizeof a
If braces are used no spaces please : sizeof(struct foo)
>
> 4c. Breaking long lines
>Descendants are always substantially shorter than the parent
>
Michael S. Tsirkin wrote (ao):
> Use tabs, not spaces, for indentation. Tabs should be 8
> characters wide.
A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
any amount of characters, right?
Sander
--
Humilis IT Services and Solutions
http://www.humilis
52 matches
Mail list logo
