Coding Standards for Gora

[Lewis John Mcgibbney <le...@gmail.com>]

Hi Keith,

On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <ke...@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.


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

Thanks

Lewis

Re: Coding Standards for Gora

[Lewis John Mcgibbney <le...@gmail.com>]

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 <en...@gmail.com> wrote:

> Hi,
>
> Some comments below.
>
> On Mon, Jan 30, 2012 at 12:00 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> > On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney
> > <le...@gmail.com> wrote:
> > > Hi Keith,
> > >
> > > On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <ke...@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*

Re: Coding Standards for Gora

[Enis Söztutar <en...@gmail.com>]

Hi,

Some comments below.

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

> On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney
> <le...@gmail.com> wrote:
> > Hi Keith,
> >
> > On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <ke...@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
>

Re: Coding Standards for Gora

[Keith Turner <ke...@deenlo.com>]

On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney
<le...@gmail.com> wrote:
> Hi Keith,
>
> On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <ke...@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.

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

>
> Thanks
>
> Lewis