db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [patch] cleanup of org.apache.derby.iapi.services.cache.ClassSize
Date Tue, 07 Feb 2006 18:17:34 GMT
I like the idea of a script run at build time that checks coding style. 
  I could get behind that.  One thing you could do to help, Kev, since 
this is your itch, is to (a) propose a coding style and (b) propose a 
process by which this style can be adhered to that is not too onerous 
such that it inhibits contributions or significantly impacts the 
productivity of developers.



Kev Jackson wrote:
>> Right, and Derby has not chosen either of those styles, the text is
>> correct in saying *individuals* have found those guides helpful.
> Ah ok, so not that these are the only style guides that contributors 
> should follow, I should read more carefully
>>> - also it's not good to have
>>> unused imports kicking around, it adds bloat to the code, and it's
>>> unnecessary, removing these wouldn't hurt regardless of the rest of the
>>> changes.
>> Agree there, removing unused imports is a good thing to do. Though they
>> don't do any harm to the runtime footprint, only the .java file and
>> cause yellow flags in Eclipse.
> This is one of my concerns, Eclipse has a pretty good warning system, 
> but if it's flooded with small silly warnings (things that should really 
> be fixed), then it's possible to miss out on the warning that's 
> important.  At the moment there are 7000+ warnings (of all different 
> types) reported by Eclipse - how many of these are really important, I 
> don't know, but by getting rid of the easy ones it's easier to see the 
> important ones where perhaps the warning should be taken seriously or 
> perhaps not.
>>> Also I'm suprised that there isn't a defined style (regardless of
>>> whether I like it or not) - every single other open source project I've
>>> worked on (Java, C, Ruby, whatever) has had a style that submitted
>>> patches must conform to before they are considered for inclusion, and
>>> it's a little odd that Derby doesn't have this.
>> It's because no one has had a stong itch to enforce a coding style, and
>> come up with the rules/process for accepting a patch or not (do we want
>> to turn away contributions due to a coding style issue, do the
>> committers want to spend their time checking coding standards). Any
>> experience you want to bring from other projects would be great here.
> The only thing I would say here is that the projects I've worked on tend 
> to be upfront about the coding style which is being enforced (Ant is the 
> Sun coding conventions (roughly), Rails is 2 spaces, no tabs, Ruby style 
> for method names, Ruby is follow the current code etc), for code that is 
> already in svn/cvs, the most sensible thing would be to gradually change 
> it as a committer comes across it, or during refactoring etc.
> As I mentioned before, it's better if there is an automated process to 
> check files so that it's not seen as a personal issue (which it isn't).  
> Jalopy, checkstyle, pmd are all good for checking Java and all can be 
> run as part of the build process (all have Ant tasks).  If a style is 
> chosen, then supplying a template file for IDEA/Eclipse/vim/emacs would 
> also be of benefit as then the developers can code how they like and the 
> IDE can massage the code into "the one true style".  An svn check in 
> script could also be used to fix up formatting before the commit takes 
> place.
> Obviously as a newcomer I don't want to rock the boat, (and style/brace 
> wars are always nasty) - hope I didn't cause offense.
> Kev

View raw message