db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <kevin.jack...@it.fts-vn.com>
Subject Re: [patch] cleanup of org.apache.derby.iapi.services.cache.ClassSize
Date Tue, 07 Feb 2006 05:20:52 GMT

>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