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