gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
Subject Re: Coding Standards for Gora
Date Tue, 31 Jan 2012 17:42:59 GMT
Hi Guys,

I've quickly created a wiki page for this [1] so it would be great if
someone could prossibly provide a more verbose account of some of the
specific coding style we wish to adopt moving forward.

Thanks

Lewis

[1]
https://cwiki.apache.org/confluence/display/GORA/Apache+Gora+Coding+Style

On Mon, Jan 30, 2012 at 9:11 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> Hi,
>
> 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
> >
>



-- 
*Lewis*

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