Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "CodeStyle" page has been changed by JonathanEllis.
http://wiki.apache.org/cassandra/CodeStyle?action=diff&rev1=16&rev2=17

--------------------------------------------------

- == General Code Conventions  ==
+ == General Code Conventions ==
- 
   * The Cassandra project follows Sun's Java coding conventions 
(http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) with an important 
exception:
-    * { and } are always placed on a new line
+   * { and } are always placed on a new line
   * Please make sure to use 4 spaces instead of the tab character for all your 
indentation
  
  == Exception handling ==
- 
   * Never ever write `catch (...) {}` or `catch (...) { logger.error() }` 
merely to satisfy Java's compile-time exception checking.  Always propagate the 
exception up or throw RuntimeException (or, if it "can't happen," 
AssertionError).  This makes the exceptions visible to automated tests.
   * Avoid propagating up checked exceptions that no caller handles.  Rethrow 
as RuntimeException (or IOError, if that is more applicable)
   * Similarly, `logger.warn()` is often a cop-out: is this an error or not?  
If it is don't hide it behind a warn; if it isn't, no need for the warning.
   * If you genuinely know an exception indicates an expected condition, it's 
okay to ignore it BUT this must be explicitly explained in a comment.
  
  == Boilerplate ==
-  
   * Avoid redundant @Override annotations when implementing abstract or 
interface methods
   * Do not implement equals or hashcode methods unless they are actually 
needed.
   * Prefer public final fields to private fields with getters. (But prefer 
encapsulating behavior in "real" methods to either.)
@@ -23, +20 @@

   * Do not extract interfaces (or abstract classes) unless you actually need 
multiple implementations of it
  
  == Multiline statements ==
- 
   * Try to keep lines under 120 characters, but use good judgement -- it's 
better to exceed 120 by a little, than split a line that has no natural 
splitting points.
   * When splitting inside a method call, use one line per parameter and align 
them, like this:
  
  {{{
- SSTableWriter writer = new SSTableWriter(cfStore.getTempSSTablePath(), 
+ SSTableWriter writer = new SSTableWriter(cfStore.getTempSSTablePath(),
-                                          columnFamilies_.size(), 
+                                          columnFamilies_.size(),
                                           StorageService.getPartitioner());
  }}}
- 
- == Private_ _Members and Underscores  ==
+ == Private_ _Members and Underscores ==
- 
   * The goal is to not have an "_" character appended or prepended to private 
variables' names
   * There's currently a lot of private variables with an "_" appended to 
them... here's our current policy on this.
-    * if you're working on a file with foo_ style private members then please 
keep using that convention.
+   * if you're working on a file with foo_ style private members then please 
keep using that convention.
-    * when writing a new class please do not name private variables w/ an 
appended or prepended "_" 
+   * when writing a new class please do not name private variables w/ an 
appended or prepended "_"
  
  {{{
  public class ExampleStuff
@@ -48, +42 @@

      private String foo;  // more better
  }
  }}}
- 
  == Whitespace ==
- 
-   * Please make sure to use 4 spaces instead of the tab character for all 
your indentation
+  * Please make sure to use 4 spaces instead of the tab character for all your 
indentation
-   * Many lines in many files have a bunch of trailing whitespace... Please 
either clean these up in a separate patch, or leave them alone, so that 
reviewers now and anyone reading code history later don't have to pay attention 
to whitespace diffs.
+  * Many lines in many files have a bunch of trailing whitespace... Please 
either clean these up in a separate patch, or leave them alone, so that 
reviewers now and anyone reading code history later don't have to pay attention 
to whitespace diffs.
  
  == imports ==
- 
  Please observe the following order for your imports:
  
-   * java
+  * java
+  * [blank line]
+  * com.google.common
-   * org.apache.commons 
+  * org.apache.commons
-   * org.apache.slf4j
-   * org.junit
+  * org.junit
+  * org.slf4j
+  * [blank line]
-   * everything else alphabetically
+  * everything else alphabetically
  

Reply via email to