db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: derby-dev Digest 14 Aug 2006 23:19:01 -0000 Issue 1202
Date Tue, 15 Aug 2006 00:11:25 GMT
You are voting on the original text.  Rick is proposing an alternative, 
which can be discussed, but not voted on at this point.

Rick, I think you need to decide if you like the text of the vote as it 
stands, or if you think it's harmful enough to warrant a veto.

I would like to humbly suggest that the change is "good enough". 
Perhaps, Rick, you could abstain from this vote, and then offer another 
vote to amend the text.  I would like to see incremental progress on 
this effort.  But it's ultimately your call, Rick.

Thanks,

David

Craig L Russell wrote:
> I'm not getting a good feeling about this.
> 
> Coding conventions are all about "religious issues". There are hundreds 
> of examples in the CodeConvTOC that are intended to be normative, and 
> they are full of advice that should not be disregarded just because you 
> have been coding longer than anyone else.
> 
> Some specific examples include where to put the opening brace for the 
> various block methods do, while, for, try, catch, finally, etc. and 
> where to indent the closing brace. When breaking lines, break before a 
> .method(...) call. Block comments use /* and not a bunch of // lines. 
> And many others. 
> 
> There are some details such as whether to put a blank character before 
> the opening parenthesis of method declarations versus method 
> invocations, and I'd like to encourage folks to read and try to 
> internalize these rules. While I wouldn't reject a patch because of a 
> missing blank, I would reject a patch that had random indentation and 
> began method bodies' opening brace on a separate line.
> 
> If we were not voting for the style guide, but merely "write clear" and 
> 3 rules, I withdraw my vote.
> 
> Craig
> 
>> Kathey Marsden wrote:
>>
>>
>>> Rick Hillegas wrote:
>>>
>>>
>>>> I don't want to stop the vote if we can avoid it. However, I have 
>>>> some misgivings that we may not agree on what we're approving. 
>>>> Everyone may be hearing what they want to hear.
>>>>
>>>>
>>> I see what you are saying about folks hearing what they want to hear.
>>>
>>>
>>>> Clarity is the key goal of Derby's coding standards. The coding 
>>>> guidelines at 
>>>> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html are a 
>>>> style primer, not a law book. Mine this document for good examples 
>>>> but use your common sense. Feel free to disregard any advice which 
>>>> is religious in nature or which would make your code brittle. Above 
>>>> all else, write clearly.
>>>>
>>>>
>>>  I don't think this wording would bring us into compliance with the 
>>> db project guidelines that we have  a "well-defined convention"  and 
>>> would create a state without a general agreed upon direction where we 
>>> are bound to have countless discussions about code formatting 
>>> "religion" as you put it.    We need an agreed upon base color for 
>>> our shed.  If as folks are painting they feel the need to vary a bit 
>>> that does not interfere with the general color scheme, add trim etc, 
>>> that is reasonable, but  we don't want to go back to a state where we 
>>> encourage everyone to grab a can of whatever color paint they want 
>>> and start painting and repainting, running colors into each other and 
>>> have to debate about it.
>>>
>>
>> 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.
>>
>>
>> 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.
>>
>>
>> Regards,
>>
>> -Rick
>>
> 
> Craig Russell
> 
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 
> 408 276-5638 mailto:Craig.Russell@sun.com
> 
> P.S. A good JDO? O, Gasp!
> 
> 

Mime
View raw message