Wiki
Clone wikiHolocore / Pull Request Checklist
Overall
- Check for Code Style to match standards
- License is included at top of each file
- Check for unnecessary code complications - easy to read!
- Everything must be consistent. Patterns and syntax in one area must match another
General Practices
- Collections
- 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<>();
- Every collection that's part of a class must be final
- When using myList.toArray(new String[myList.size()]) - the array supplied as an argument must have the same size as the list itself
- 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"); }
- 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);
- The data type for a collection must be one of: Collection, List, Set, or Map
- Strings
- Any string creation done in a loop should use a StringBuilder
- 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
- No string-based compare for game logic, instead use enums if possible
- Intents
- Broadcast is called
- All member variables are final and there are no setters
- Registration is done in the constructor of the service
- Java Classes
- No direct variable access of another class, even an inner class
- BAD: obj.myVar = 2;
- GOOD: obj.setMyVar(2);
- Variable/Function Ordering:
- 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
- Methods should go: public, protected, private
- With services: Constructor, initialize, start, stop, terminate, private methods (no other public methods)
- Variables should go public static final, private static final, private final, private
- Methods should be less than 30 lines of code
- 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
- 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
- Make functions and classes static where possible
- No direct variable access of another class, even an inner class
- Exceptions
- All exceptions should be printed using Log.w(exception) or Log.e(exception)
- Output
- Only use Log functions, no System out/err
- When doing a load output like "Loading objects..." "Loaded %d objects in %.2fms" - use the class StandardLog
- Don't leave excessive debug logs in code
- 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
- Java APIs
- 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
- Java Primitives
Updated