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 04:45:10 GMT
Daniel John Debrunner wrote:

>Kev Jackson wrote:
>  
>
>>Following on from yesterdays post, here's a patch that tries to get this
>>class to conform to the coding standards chosen by the Derby developers
>>    
>>
>
>Except that we have not chosen a coding standard. :-)
>
>http://wiki.apache.org/db-derby/DerbyContributorChecklist
>  
>
In both coding standards listed (Java Code style from Sun and the 
Geronimo code style), this class does not conform to either style

>and in another e-mail:
>  
>
>> I'm willing to contribute as I'd like to learn a bit about how databases work under
the hood,
>>but I can't stand the current code style and I'd like to know if this is an agreed
upon convention,
>>or a legacy of the various owners of the codebase up to now.
>>    
>>
>
>The history of the code (from its inception over 8 years ago) was that
>the only coding standard in force was to be clear, and don't make
>changes in the code just for formatting sake. It was just not worth the
>time originally to try and get everyone to agree on a single standard,
>some people like braces one way, some the other, some like spaces in
>different positions in loops or if statements etc, sometimes a single
>rule is not applicable for all situations etc. etc.
>
>  
>
if (condition)
  do something;

is clear except when you see

if (condition)
  return foo;
  return bar;

(and an example of this can be found in the code that I changed (ie the 
one in svn right now))

>The issue is that you say you can't stand the current code style, but
>maybe someone else can't stand a code style you like, hard to please
>everyone. :-)
>
>  
>
Understood and a good way to compromise is through the enforcement of a 
standard through something like checkstyle (so the machine is to blame, 
not a person!) - but note that first I asked about style, then I was 
directed to two (slightly different) styles linked to from the wiki and 
this class didn't conform to either of them - hence I assumed that it 
was worth refactoring a little to conform - 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.

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.

>Please do get involved in Derby, look at the jira issues marked with a
>component of Newcomer, or fix a bug thet scratches your itch with Derby.
>Many on the list will be willing to guide you, just ask.
>
>  
>
>>- remove unused import
>>- change static final variables from camelCase to CONST_NAMES (except
>>where they are public and could be used elsewhere BWC concern)
>>    
>>
>[just curious, what's BWC?]
>  
>
BWC = BackWards Compatibility, this is #1 priority over at Ant, so I 
assumed that no changes should be made to public values/methods to 
prevent any BWC problems

>  
>
>>- add {} for conditionals
>>- strip lots of extra white space
>>    
>>
>
>As Myrna said, these type of changes can cause problems for merges of
>fixes across branches and also to others with existing edits against the
>same files.
>
>  
>
>>As for the CLA/ICLA, I've already signed one (for ant), so do I need to
>>sign another for Derby?
>>    
>>
>
>Nope, I belive a single ICLA at the ASF is sufficient.
>  
>
Ok, well that's one question answered :)

Kev

Mime
View raw message