db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: derby-dev Digest 14 Aug 2006 23:19:01 -0000 Issue 1202
Date Mon, 14 Aug 2006 23:51:14 GMT
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