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<[email protected]> > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
