db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [VOTE] Approve coding conventions for the Derby project
Date Tue, 15 Aug 2006 13:00:09 GMT
Kathey Marsden wrote:

> 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 incubation.
>
>> 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.

I'm not sure I understand this point. If we recommend a style primer, 
then I think we're saying that the style is safe and we don't expect 
committers to flunk a conforming patch for style reasons--provided, of 
course, that the code is clear. "Recommended" means "safe". I'm just 
saying it doesn't mean "mandatory". I don't think our perspectives are 
that far apart.

>
> 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 covered.

I think we can always tighten up the rules if we discover that we are 
flunking patches for recurrent reasons. So far, it's mostly been an 
issue of tabs/spaces/line-lengths.

>
> 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.

Please see my earlier comment. I think we agree on this one. 
"Recommended" means "safe" (provided that the patch is clear).

>
> Thanks
>
> Kathey
>
>


Mime
View raw message