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. 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? 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. > > Thanks! > -Garrett > -- Michal Simek, Ing. (M.Eng) PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663 ------------------------------------------------------------------------------ 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
