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
14 matches
Mail list logo
