Code Style

Code Style

General Code Conventions

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.


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

  • Prefer requiring initialization in the constructor to setters.

  • Avoid redundant this references to member fields or methods.

  • Do not extract interfaces (or abstract classes) unless you actually need multiple implementations of it.

  • Always include braces for nested levels of conditionals and loops. Only avoid braces for single level.

Multiline statements

  • Try to keep lines under 120 characters, but use good judgement. It is 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 the items called:

SSTableWriter writer = new SSTableWriter(cfs.getTempSSTablePath(),
  • When splitting a ternary, use one line per clause, carry the operator, and align by indenting with 4 white spaces:

var = bar == null
    ? doFoo()
    : doBar();


  • Make sure to use 4 spaces instead of the tab character for all your indentation.

  • Many lines in the current files have a bunch of trailing whitespace. If you encounter incorrect whitespace, clean up in a separate patch. Current and future reviewers won’t want to review whitespace diffs.


Observe the following order for your imports:

[blank line]
[blank line]
everything else alphabetically

Format files for IDEs