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 Mon, 14 Aug 2006 14:37:36 GMT
-1

On the whole, I think that the proposed guidelines are decent. However, 
I would like us to emphasize that these are guidelines and not laws.

1) If we want to adopt a set of laws, then brevity is the soul of wit. 
The hard-and-fast laws should fit on a single page so that you can know 
at a glance what conforms.

2) The key goal is clarity. This does not come across in these 
guidelines. Sometimes you have to break guidelines in order to be clear. 
This is the chief piece of advice from Strunk and White's The Elements 
of Style and from Kernighan's The Elements of Programming Style.

3) There are some religious doctrines in the proposed guidelines. Brace 
placement, in particular, is purely a matter of style. Let's leave that 
to the individual's taste. I would not outlaw the following code 
snippet. In my opinion it is a model piece of code, concise and clear, 
even though it violates the proposed bracing religion:

   if ( featureEnabled ) { return; }

-Rick

Kathey Marsden wrote:

> This is a vote to define the coding conventions for the Derby project 
> per the db project guidelines http://db.apache.org/source.html
> Vote closes  10:00am, Wednesday, August  15.
>
> [+1]  Adopt the coding convention described.
> [-1 ] Do not adopt the coding convention described.
>
> The conventions outlined below will be published on the wiki page 
> http://wiki.apache.org/db-derby/DerbyContributorChecklist
>
> Derby uses the "Code Conventions for the Java Programming Language"
> (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) with these
> amendments:
> - space indentation (no tabs).
> - Derby does not discourage deferring variable declaration to the 
> first use.
> - Lines should be limited to 80 characters
> - @author tags should not be used at all
>
> Note: There is a great deal of existing code that does not match this
> convention. Changes to existing code should match the surrounding code
> for readability, matching tabs or spaces as appropriate (see Tabs) .
> Patches should not have white space diffs. Code and diffs should be
> readable in  context.
>
>
>


Mime
View raw message