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.

Thanks,

David

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

Mime
View raw message