On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney <[email protected]> wrote: > Hi Keith, > > On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <[email protected]> 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
