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....@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 > > <lewis.mcgibb...@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*
