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).
> I've been tasked with edicating some new hires on linux kernel coding style.
> While we have Documentation/CodingStyle, it skips detail that is supposed to
> be learned by example.
>
> Since I've been burned by this a couple of times myself till I learned,
> I've put together a short list of
I've been tasked with edicating some new hires on linux kernel coding style.
While we have Documentation/CodingStyle, it skips detail that is supposed to
be learned by example.
Since I've been burned by this a couple of times myself till I learned,
I've put together a short list of rules
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
28 matches
Mail list logo
