Wiki

Clone wiki

Holocore / Pull Request Checklist

Overall

  1. Check for Code Style to match standards
  2. License is included at top of each file
  3. Check for unnecessary code complications - easy to read!
  4. Everything must be consistent. Patterns and syntax in one area must match another

General Practices

  1. Collections
    1. The data type for a collection must be one of: Collection, List, Set, or Map
      • BAD: ArrayList<String> myList = new ArrayList<>();
      • GOOD: List<String> myList = new ArrayList<>();
    2. Every collection that's part of a class must be final
    3. When using myList.toArray(new String[myList.size()]) - the array supplied as an argument must have the same size as the list itself
    4. Any use of collections must guarantee some form of thread synchronization. This usually means creating a synchronized block on the collection when it's accessed:
      • synchronized (myList) { myList.add("Hello World"); }
    5. When returning a reference to a collection, it must be either a copy or an unmodifiable wrapper of the collection. Examples:
      • return new ArrayList<>(myMap.values());
      • return Collections.unmodifiableList(myList);
      • return new ArrayList<>(myList);
  2. Strings
    1. Any string creation done in a loop should use a StringBuilder
    2. Any use of str.split("") that expects a certain number should use: str.split("", n) - where n is the expected size of the array. If it is less than that, that should be handled
    3. No string-based compare for game logic, instead use enums if possible
  3. Intents
    1. Broadcast is called
    2. All member variables are final and there are no setters
    3. Registration is done in the constructor of the service
  4. Java Classes
    1. No direct variable access of another class, even an inner class
      • BAD: obj.myVar = 2;
      • GOOD: obj.setMyVar(2);
    2. Variable/Function Ordering:
      1. Variables should go public static final, private static final, private final, private
        • In almost no situation do you want a static variable that isn't final
      2. Methods should go: public, protected, private
        • With services: Constructor, initialize, start, stop, terminate, private methods (no other public methods)
    3. Methods should be less than 30 lines of code
    4. Methods should do basic state checks at the beginning via Assert or if () { return; }
      • Java is faster at doing checks at the beginning then returning, it also makes it clear what the requirements are of the function
    5. Switches containing case statements shouldn't define variables, but if they do, add parenthesis around the whole case statement to limit the scope of the variable
    6. Make functions and classes static where possible
  5. Exceptions
    1. All exceptions should be printed using Log.w(exception) or Log.e(exception)
  6. Output
    1. Only use Log functions, no System out/err
    2. When doing a load output like "Loading objects..." "Loaded %d objects in %.2fms" - use the class StandardLog
    3. Don't leave excessive debug logs in code
    4. Use the appropriate function in Log for what the output is:
      • v is for verbose output that's almost too much to handle, but is very helpful for debugging when enabled
      • d is for debug output that's not too excessive but is enough to debug most issues, especially concurrent ones
      • i is for info output that is good at a high level management perspective
      • w is for warning output where something could go wrong in the future because of this
      • e is for error output where something went wrong and it isn't very recoverable
  7. Java APIs
    1. Java Primitives
      • Use primitives (byte, char, short, int, long) when possible
      • When parsing a primitive, use the functions Byte.parseByte, Integer.parseInt, etc. to avoid unnecessary autoboxing

Updated