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
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 look more
>> >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
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
>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,
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 indentation
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 case in a switch
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
>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
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
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
>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
>> 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
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 132409*
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 and
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, it's all nicely explained at
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 function
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 foo: labels also...
No, the word case never starts at column 1 (counting from 1), but at least
in column minimalIndent, where minimalIndent is the
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 foo: labels also...
No, the word case never starts at column 1 (counting from 1),
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.
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
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).
ether a short list of rules complementing
> Documentation/CodingStyle. This list is attached, below.
Here's an updated version of the boring list.
My thanks to everyone who commented on the first draft.
---
kernel guide to space AKA a boring list of rules
http://www.mellanox.com/mst/boring.txt
T
complementing
Documentation/CodingStyle. This list is attached, below.
Here's an updated version of the boring list.
My thanks to everyone who commented on the first draft.
---
kernel guide to space AKA a boring list of rules
http://www.mellanox.com/mst/boring.txt
This text deals mostly
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).
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 this
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 hope
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:
> > > >>
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
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
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
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
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 to
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 before
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 the
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:
On Jul 20, 2005, at 20:45:21,
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
"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
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:
> > >
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*
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
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
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
>> (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
(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 %5d%5d
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
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 one
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 patches
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].HostAdapterResetsCompleted *cough*
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...]
*cough*
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 whether
Miles wrote:
CodingStyle is vague on the issue, though ...
Perhaps we should call it coding_style grin.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
-
To unsubscribe from
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)",
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
> > 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;
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,
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
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
> 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
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 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 them
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 practice is struct
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, expand tab chars
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
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 rule is that
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 %5d
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), and whitespace
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
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
>> 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,
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
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
>
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
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
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
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
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 ...
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, but it
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 the number
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 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; /*
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; /*
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
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
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
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:
struct s {
int
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 tabs:
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
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(...)
{
...
}
I like
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
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; /*
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; /* comment */
};
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
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
>
1 - 100 of 106 matches
Mail list logo
