gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: Coding Standards for Gora
Date Mon, 30 Jan 2012 21:11:11 GMT

Some comments below.

On Mon, Jan 30, 2012 at 12:00 PM, Keith Turner <keith@deenlo.com> wrote:

> On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney
> <lewis.mcgibbney@gmail.com> wrote:
> > Hi Keith,
> >
> > On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <keith@deenlo.com> wrote:
> >
> >>
> >> Do you guys have any coding standards?  Accumulo settled on some
> >> standards for indentation, etc.  Its on our source web page [1].  I
> >> did not see anything like that on the Gora web site.
> >>
> >
> > Ripping this from your previous thread, I will start by saying that no, I
> > don't think we do have any standard coding practice as of yet. This is
> > something which we could possibly migrate to Gora from Accumulo... Wdyt?
> > This should be added to the wiki page I think.
> >
> When we started as an apache Project, someone suggested that we adopt
> a coding style from the beginning.  So we did.  We took the Lucene
> style and modified it slightly.  I think Hadoop also uses the Lucene
> style, but I am not positive about this.
> The modifications to the Lucene style that I can think of are as follows :
>  * Increased line wrap to 160 columns  (we did not like wrapping at 80)
>  * Use a new line with single statement if/else blocks instead of
> single line (we did not like how this looked)
> Could diff the Eclipse formatting XML to get a complete list.
> For Gora, if a coding style was adopted would need to decide how to
> implement it and what style to adopt.  Do you just apply to new code
> going forward or pick a date and reformat all of the code?  We just
> picked a date and reformatted all of the code using Eclipse soon after
> importing into Apache svn.

Most of the styling in Gora comes from the Hadoop/lucece world, but there
is no strict enforcement
to do this. It is also very similar to the sun spec except 2-spaces for
tabs. Other than that, we can just copy
one of the wiki pages + checkstyle conf from either of the related
projects, and modify that to suit our needs.

For the existing code, I think we can just create an issue, and apply the
patch there.

> >
> >>
> >> Also, do you code review committers changes or use lazy consensus?
> >>
> >
> > Right now we've been using a combination of both, for example some of us
> > are using Gora with HBase and others with Cassandra, this means that it
> > might be a bit difficult to test HBase stuff if you're a Cassandra user
> and
> > vice versa. I think we've found a happy medium between mostly lazy
> > consensus followed by mainly dev@ discussion should there be any
> problems...
> That sounds very reasonable.  So I can make changes to Accumulo store
> as needed but look for consensus before making other changes.
Historically, we do pre-commit reviews, and lazy consensus. It is also ok
to commit trivial stuff without a jira or review.
However, for anything that is non-trivial, it is best to open a jira,
attach the patch, and ask for a review. If no interest comes up after
some time, we can assume lazy consensus.

> >
> > Thanks
> >
> > Lewis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message