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