db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [VOTE] Approve coding conventions for the Derby project
Date Mon, 14 Aug 2006 23:37:08 GMT
First I want to say that I hope the community will continue to vote on 
this issue while discussion is underway about whether or not Rick will 
veto. I am sure the next person to take a shot at this will appreciate 
knowing where everyone stands even if it doesn't pass this round.   See
 http://db.apache.org/decisions.html  for responsibilities and 
definitions of voting.    I think this is a consensus vote. 

 Rick Hillegas wrote:

> Just want to make sure we have realistic expectations for this vote: 
> Since we are not bulk-reformatting the code, even after this vote 
> Derby won't conform to the db project guidelines.
Yes, my hope is that incrementally we can reach a point where we conform 
to the db project guidelines.  The question is how much closer we can 
get to that now.  I tend to think, the lack of such a convention for 
Derby was just a serious oversight in allowing Derby to graduate 

> The guidelines don't specify how extensive the hard-and-fast rules 
> have to be. To date, here are the only ones I think we have discussed 
> extensively:
> 1) No tabs.
> 2) Indentation stops set at 4 spaces.
> 3) Line length not to exceed 80 characters.
> To this, with the community's approval, I would add
> 0) Write clearly.
> A good enough coding standard would be these 4 hard-and-fast rules 
> plus a pointer to a non-binding style primer. Let's keep it simple and 
> focus on the issues which actually bothered us.
If incremental consensus has to start there, I suppose it could, but  I 
don't think it would qualify as a "well-defined convention" and I do 
think we would need to adopt a well-defined convention in the future in 
our work to comply with the db project guidelines.      I am curious for 
matters of db project guidelines, who could answer what level of 
specificity is required.

I disagree that this would solve all the issues.  I think still there 
would be issues with IDE's reformatting code, various religious 
discussions around particular changes  and the core problem  would 
remain (even after removal of the note) that a new developer can't  rely 
upon setting their IDE to some documented convention and be sure they 
won't get into trouble with it.  I think we need to be setup so it is 
easy to join the project and make a fix.    Those making changes for 
style need to make sure that their style decisions are not going to 
interfere with anyone using the documented convention and that is it.  
That is not possible with the 4 rules and primer pointer wording.

It is different from closed source where we might expect some small 
group of core developers to learn how to work around and integrate each 
other's styles.  ( I actually have a .emacs file  that seems to have the 
beginning of this conversation years ago,  I am not even sure who wrote 
it or who "I" is in this context, but it  has various commented out 
sections and says .." Nat's favorite is ... Ame's said ....  I  like it 
like ...  We still haven't decided about switch statements" etc.)   This 
kind of thing does not scale well to an open source project with 
potentially hundreds of  contributors all showing up to build great  
extensions and and make fixes just want to know  some format to use that 
won't get them into trouble.  They don't really care what color the shed 
is, just give them something that works and if we are not militant about 
it and allow variations that make sense and don't interfere, then we are 

I think we should publish the convention as proposed and our ultimate 
goal should be that anyone formatting their code in this way is not 
going have to ever redo their patch based on formatting issues.


View raw message