elytra-code-guidelines.md

Elytra Code Style Guidelines

These are guidelines. Feel free to ignore them. Use your judgement.

Indentation

Tabs and spaces. Tabs for indentation, spaces for alignment. Reasoning: Tabs are more semantic, and their size can be adjusted to the reader's preference.

If changing the indent size in your editor misaligns the code and makes it unclear, you did it wrong.

{
 →  doTheThing(
 →  ···········"aligned argument",
 →  ···········"aligned argument 2",
 →  ···········"aligned argument 3"
 →  );
}

Braces

Same-line.

if (foo) {

} else {

}

Line Length

• Documentation: 80 columns.
• Code: 120 columns, wrap to 80 columns when it makes sense.

Spacing

Spaces before and after operators, spaces after keywords, spaces before braces.

if·(foo·==·bar·&&·a·<=·5)·{

Comments

Written as full sentences with punctuation and proper case, to make it easier to add on to later. If it spans multiple lines, use /* block comments */.

Task Tags

• XXX: Take note. Use to comment code that is counter-intuitive or may have issues.
• TODO: Needs improvement. Use to comment code with suggested next-steps and improvements.
• FIXME: Possibly broken. Use to document known failing edge cases.

Instanciation

Prefer Guava utility classes where they exist. (e.g. Lists.newArrayList()).

Where they don't, use the diamond operator whenever possible. (e.g. new WeakHashMap<>())

Lambdas

Use whenever possible, unless unclear. Prefer Guava classes to Java classes to maintain Java 6 compatibility.

Encoding

Always UTF-8. Newlines must be Unix-style (\n) in repositories. Windows-style (\r\n) is not acceptable within repositories.

Switches

Indented with braces. Braces are optional but preferred.

switch (foo) {
→  case 1: {
→  →  break;
→  }
→  default: {
→  →  break;
→  }
}

Ifs

Always use braces, except for single throw/return/break/continue statements.

if (1 == 2) throw new AssertionError();
if (4 != 4)
→  throw new AssertionError("THE UNIVERSE MAKES NO SENSE");
if (4 == 9) {
→  // do something
}