IntelliJ Coding Standards

IntelliJ Spartanizer's Coding Standards

This wiki page will cover the coding standards used throughout the project, which one must follow in order to contribute to this project. Most requirements will follow the Java 8 spirit, along with some that are unique for this project.

Class Documentations

Each class must have a Javadoc preceding its declaration that includes the author of the class, and the date it was created. Preferably, this Javadoc will also include a short explanation about the class and how to use it. Use the following format:

/**
 * @author Michal Cohen, Roey Maor, Anna Belozovsky, Oren Afek, Amir Sagiv, Roei Raz, Sharon Levenzon Kuninin
 * @since 25/3/17
 *
 * <short explanation about the class>
 */

Stream API

Use the newly introduced stream API instead of old fashioned loops. This means that simple loops that operate on all variables, perform maps, reductions, etc... should be replaced with the appropiate calls to the functions in the stream API. Of course not all for loops can be replaced with stream calls - use your discretion and tools provided by IntelliJ to make sure the new API is used where possible. Instead of:

List<Integer> l = Arrays.asList(1, 2, 3, 5);
for (Integer i : l) {
    System.out.println(i);
}

write:

List<Integer> l = Arrays.asList(1, 2, 3, 5);
l.forEach(i -> System.out.println(i));

or even better:

List<Integer> l = Arrays.asList(1, 2, 3, 5);
l.forEach(System.out::println);

Return Empty Containers Instead of nulls

When a method returns a containers and receives an illegal parameter, an empty containers should be returned instead of null. For example, instead of writing the following method:

public List<Integer> yes(String a) {
    if (a == null) {
        return null;
    }

    return Arrays.asList(1, 2, 3);
}

you should write something like:

public List<Integer> yes(String a) {
    if (a == null) {
        return new ArrayList<>();
    }

    return Arrays.asList(1, 2, 3);
}

This prevents overhead caused by many null checks.

Perform null Checks Unless it Ruins Fluent API

A function should always perforn null checks to avoid unexpected NPEs, unless, it ruins fluent API where an NPE cannot be thrown. For example:

e.getParent().getFirstChild().getText().equals("pineapple");

the #getText() method might return null, but not in this context. If we were to perform null checks in this code, it would ruin the fluent API and overhead the code with needless checks.

Use Class#simpleName() Instead of Other Alternatives

When using reflection and tasked with receiving the name of a class, there are three major options:

• Class#simpleName()
• Class#canonicalName()
• Class#name()

In most cases, in this project, the usage of Class#simpleName() should be prefered over the other 2.

Lambda Expressions

λ expressions should be used whenever possible, insted of creating anonymous classes.

Javadocs

Document your code, please.

All public and protected methods must have well written Javadocs, while line comments should be used where the purpose of the code is not obvious to the reader.

Use Interface with Default Methods

Prefer using interfaces with default methods instead of abstract classes where possible, mainly if the abstract classes don't require fields.

Method References

Use this syntactic sugar where possible (IntelliJ should aid you in this task). Instead of writing the following:

Stream.of("111", "22", "3").map(s -> s.length()).forEach(i -> System.out.println(i));

this syntactic sugar shortens it and makes it much more readable:

Stream.of("111", "22", "3").map(String::length).forEach(System.out::println);

Short and concise variable names

Preferably one word, formatted in camel case

Use the most recent version of Intellij

This means the latest version available as of writing this, meaning 2017.1 https://www.jetbrains.com/idea/download/

Use the most recent version of JDK

This means the latest version available as of writing this, meaning 8u121 http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

When declaring variable types, use the the highest ancestor type possible

For example if B is derived from A, one should replace (when possible)

List<B> l = new ArrayList<>()

with:

List<A> l = new ArrayList<>()

Also, declarations like this one:

Object wth = new ArrayList<>()

should never exist

Warnings Policy

see issue #131

inspections that should be turned off

The inspections menu resides in settings>Editor>Inspections. There, choose to disable the inspection (which will disable the related warning): Java > Declaration redundancy > Declaration access can be weaker

Spartanization

All included code should be spartanized prior to inclusion, unless spartanizing it will cause issues with it's functionality