[U-Boot-Users] Enforcement of coding standards

Thu Mar 6 17:16:30 CET 2003

I don't really want to get into the politics of when patches should be
accepted/rejected, but I do agree that we need to have an honest (and
friendly!) discussion of the #ifdef mess and coding standard enforcement
issues.

Both Robert and Wolfgang have fair points.  From Robert's point of view why
be picky about formatting when the rest of the source isn't as neat as it
could be.  And from Wolfgang's point of view, why add more messy code - that
will just make things worse.

Maybe we could have a blitz on everything where we just check and fix
adherence to the coding standards - no functionality changes, just
readability.  Once we have the codebase in a 'tidied' state then Wolfgang
can more justifiably reject patches if they don't meet the standards.  

I think we can all agree that in places the source is a little untidy, and
that we wish to aim towards as readable and clear tree as we can - so let's
pull together and sort it out!

Thanks

Chris.

> -----Original Message-----
> From: Robert Schwebel [mailto:r.schwebel at pengutronix.de]
> Sent: 06 March 2003 16:08
> To: U-Boot Mailing List
> Subject: Re: [U-Boot-Users] [PATCH] 2/9: bootp
> 
> 
> On Thu, Mar 06, 2003 at 04:31:10PM +0100, Wolfgang Denk wrote:
> > Robert, what do you want to demonstrate?
> > 
> > That U-Boot was not written by one single person, stickng 
> to  exactly
> > one  coding  style?  That  there  are  deficiencies,  both 
> formal and
> > functional?
> > 
> > What you do right now is not helpful. You have enough  
> experience  to
> > provide  really  valuable  input - see some of your 
> previous patches.
> > Please try to focus on substantial things, and concentrate  
> on  fixes
> > and extensions.
> 
> You want open words, ok, here we go. 
> 
> Don't get me wrong, I generally have no problem with maintainers
> rejecting my patches.  It's quite normal that maintainers know their
> projects much better than I do, so I'm used to going back to 
> the lab and
> reworking stuff when it's necessary. 
> 
> My problem is that your argumentation regarding the "little things" is
> not easily understandable. You have a document in your code which says
> that Linux coding style should be used. If I send patches which fix
> coding style (and yes, it's only in source files I have worked on,
> otherwhise I wouldn't have found it) they are rejected. You 
> say: improve
> documentation; if I find something and do it you reject it 
> because it is
> not _exactly_ how you would have done it or how you did it. I try to
> improve usability by making help messages more understandable, because
> I, when I first tried to _use_ them didn't understand them and had to
> look at the source first (every good engineer should know how 
> important
> the grandma test is ;). You reject them because I add 10 
> bytes to a 100
> KiB bootloader. I try to improve #ifdef mess (and there's a lot of it
> left, I can tell you!) by using all the well known techniques 
> like debug
> macros etc. You reject them because it doesn't change functionality. I
> try to make code better readable by unsing correct indentation - you
> reject it. Then, after all that 'it-doesn't-matter-how-the-code-looks-
> like-if-it-works' I add two lines with
> 
> //#define foo
> #undef foo
>  
> and you tell me that it's against the coding style. My impression is
> that you didn't care a single bit about coding style with the other 
> 3.2 MiB of the code, so why do you care about my little improvements?
> It's not that easy to understand.  
> 
> Wolfgang, all these puzzle pieces are not worth to be 
> mentioned when you
> see them separately, and I definitely have better things to do than
> starting flame wars. But all that stuff together - including your
> sometimes a little bit rude RTFM postings addressed to people who are
> _not_ as deep into the project as you are - definitely don't 
> improve the
> mood of the developers here. 
> 
> Enough said - I would love to see an open discussion about how to
> improve the coding style / #ifdef problems. 
> 
> Robert 
> -- 
>  Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>    Braunschweiger Str. 79,  31134 Hildesheim, Germany
>    Handelsregister:  Amtsgericht Hildesheim, HRA 2686
>     Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of 
> TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you 
> feeling lost and 
> disoriented. TotalView can help you find your way. Available 
> on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
> 

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________