Re: [LTP] Submitting patch

[Garrett C. <yan...@gm...>]

On Tue, Aug 4, 2009 at 1:37 AM, Michal Simek<mic...@pe...> wrote:
> Garrett Cooper wrote:
>> On Mon, Aug 3, 2009 at 7:46 AM, Michal Simek<mic...@pe...> wrote:
>>
>>> Cyril Hrubis wrote:
>>>
>>>> Hi!
>>>>
>>>>
>>>>>> What's wrong with linux kernel coding style? Most of the decent text editors
>>>>>> that are used these days (vim, emacs...) just helps format code like this. (Eg.
>>>>>> default intendation is done by tabs and so on...) I don't like the idea
>>>>>> changing tabs to spaces before sending a patch.
>>>>>>
>>>>>>
>>>>> There is only one thing which is IMHO not good - it is 80 char line size.
>>>>> I would prefer longer lines (maybe 120 chars).
>>>>> This is for C code not for any other.
>>>>> Are you ok with it?
>>>>>
>>>>>
>>>> Well, I'm not happy with very long lines, but there are indeed circumstances
>>>> where long lines are best solution.
>>>>
>>>>
>>> I am not happy with it too but there are some cases where is really ugly
>>> to have 80chars lines.
>>>
>>
>> IMHO 95% of the time you can get away with shorter lines with
>> different constructs or more clever indentation.
> I don't want to do any clever indentation. This discuss is again and
> again the same!!!
>
> I vote for standard linux indentation - tab (size 8 chars) for whole C code.
> Follow linux kernel coding style for whole C code. As we discussed in
> this thread 80 chars line are strongly recommended.
> For checking C source code use checkpatch.pl script which is in linux
> kernel before sending patches to mailing list
> and of course checking patches before applying.

Sorry -- clever's a lowsy adjective. Let me demonstrate what I mean:

int value = a_really_long_syscall_name("format string: %s %s %s %s %s %s %s",
					field1, field2, field3, field4, field5,
					field6, field7);

int value = a_shorter_syscall("format string: %s %s %s %s %s %s %s",
			       field1, field2, field3, field4, field5,
			       field6, field7);

Please note that in both cases I used tabs to indent the fields, and
although it looks fine in vim or in any plaintext fixed-width font
editor, it looks ugly in this gmail window.

Regardless -- does checkpatch.pl appropriately detect proper
indentation on the 2nd~3rd indent? _That_ is what I was trying to
illustrate when I said `clever indenting'.

[...]

>> Take for example what
>> I just did with delete_module* -- now that was a mess to cleanup, but
>> quick nonetheless and necessary:
>> http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module01.c?view=log&pathrev=makefile_infra_rework
>> , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module02.c?view=log&pathrev=makefile_infra_rework
>> , http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/module/delete_module/delete_module03.c?view=log&pathrev=makefile_infra_rework
>>
>> We should aim for 80 column lines wherever possible because it's the
>> defacto standard, and where we can't do that (and there are a handful
>> of areas with shell code and Makefile code where I couldn't without
>> changing the meaning of the message I was trying to convey), we should
>> go over 80 cols.
>>
>> At least that's how every project I know has done it.
>>
>> General rules of thumb for shell / python / perl code (from dealing
>> with other projects) was 4 space indents. Perl tends to go whacky
>> though because of all of the different ways to express constructs
>> though xD.

Thanks!
-Garrett