You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Andrew McIntyre <mc...@gmail.com> on 2006/08/12 02:09:41 UTC

Re: [VOTE] Approve coding conventions for the Derby project

On 8/11/06, Kathey Marsden <km...@sbcglobal.net> 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.

+1

andrew

Re: [VOTE] Approve coding conventions for the Derby project

Posted by Kathey Marsden <km...@sbcglobal.net>.
Manish Khettry wrote:

>I see that we're deferring tabs vs spaces and the "{"
>position issue for later.
>
>  
>
The convention does cover the  "{" position. and the long term strategy 
for spaces vs tabs.

Inspired by the Wiki  
http://wiki.apache.org/db-derby/IncrementalDevelopment page,
I am  trying the  IncrementalConcensus approach #:)

Steps are:

1) Decide upon long term coding conventions (This vote)
2) Determine long term strategy for consistent code formating and 
spacing of the code.  (My initial thought is reformat all the codelines 
but there is debate on this point.  Other solutions may present themselves)
3) Assuming some large scale action is needed, recruit  some detail 
oriented  volunteer to perform the deed when it needs to occur. (Such a 
task is not in my skill set)
4) Gain consensus on a date for the  large scale action if needed.
5) Volunteer executes large scale action if needed.
6) Remove the "Note:" section of the convention.
7) Put this whole mess behind us and enjoy a world without white space 
diffs wasting everyones time, impeding review,  and hiding bugs in the 
product.

Of course how far we get down this path remains to be seen.  I think 
each incremental step achieved will be useful even if we get stuck along 
the way.

Kathey



Re: [VOTE] Approve coding conventions for the Derby project

Posted by Manish Khettry <ma...@yahoo.com>.
+1

I see that we're deferring tabs vs spaces and the "{"
position issue for later.

--- Andrew McIntyre <mc...@gmail.com> wrote:

> On 8/11/06, Kathey Marsden
> <km...@sbcglobal.net> 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.
> 
> +1
> 
> andrew
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com