Re: [LTP] Submitting patch

[Subrata Modak <subrata@linux.vnet.ibm.com>]

Hi Michal/Garret/all,

On Tue, 2009-08-04 at 10:37 +0200, Michal Simek wrote:
> Garrett Cooper wrote:
> > On Mon, Aug 3, 2009 at 7:46 AM, Michal Simek<michal.simek@petalogix.com> 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.
> 

Yes, checkpatch.pl for C code patches.

> Cyril, Mike, Subrata and others: Can you send us your opinion? I don't
> want to spend my time with discuss about it.
> 
> I am not interested in any other code that's why I don't write any
> comment to it.
> You can choose what you want. Of course if is similar utility like
> checkpatch.pl it will be good to use it and not to check
> it by hand.
> 
> Subrata can we please write output from this discussion to web / doc
> somewhere?
> 

I will do that soon.

> Thanks,
> Michal
> 
> 
> > 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.

Again, checkpatch.pl for non-C code as well. But, need to carefully
review the errors it will generate for non-C code like the Makefiles,
perl, shell, python, etc.

Garret,

Can you please come up with a list of exceptions for
     1. line length,
     2. tab length,
     3. etc

for non-C code like the perl, Makefiles, etc. I would then document them
all.

Regards--
Subrata

> >
> > Thanks!
> > -Garrett
> >   
> 
> 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list