You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Basics

We largely follow Hadoop coding guidelines:

  • Use 2 (TWO) spaces to indent code.
  • Use LF (Unix style) line endings.
  • Do not use the @author Javadoc tag. (Be modest ! :-))
  • For the rest, follow the original Sun Java coding conventions.
  • If some file has different formatting, try to match the existing style.
  • Use CheckStyle to verify your coding style.
  • Avoid mixing both style and functionality changes in one commit.
  • Make sure all files have the needed license header.

Comments

We require to add comments to generate proper javadoc pages. In addition to this requirement, we encourage committers to add comments (if needed) to make code easier to understand. 

  • Class
  • Interface
  • Public constructor
  • Public method
  • Important fields
  • Code part that captures complex logic

On immutability of why you should make everything final

REEF favors immutable objects over mutable ones. When you browse the code base, you see that there is an enormous number of final and readonly modifiers used. The reason for this stems from the distributed and parallel nature of REEF: What cannot be changed doesn't have to be guarded with locks. Hence, immutability is an excellent tool to achieve both thread safety and performance. Following this line of thought, we arrive at the following guidelines:

  • Make all instance variables possible final.
  • Use the Java Concurrency in Practice annotations for the instance variables that aren't final.
  • When a class has more than 3 non-final instance variables, consider breaking the class in two to limit the lock complexity.
  • No labels