Hi, On Tue, Aug 4, 2009 at 2:07 PM, Michal Simek<[email protected]> 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. > > Cyril, Mike, Subrata and others: Can you send us your opinion?
i agree with Michal Simek. Best regards, Naresh Kamboju >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
