StyleGuide.md

Streamlines Style Guide

1. Unless stated otherwise below, code style conventions should follow Oracle's 1997 Java Code Conventions document. https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
2. Almost all methods and classes should be documented with /** */ using standard Javadoc annotations. Even if methods are trivial, classes should have some comment and the copyright notice if in server or shared module. Do not comment methods that override/implement interfaces or abstract classes because when using polymorphism these will likely not show up. Instead, put additional comments in the class description. Private methods and private nested classes may also be excluded from getting comments.
3. Only use the static keyword for things that transcend class instances not just because the class is used only once. Static variables are not garbage-collected so they should not be abused. Similarly, do not abuse the singleton pattern. Singleton should be used for things like a Null Object. Having singletons everywhere makes things far more difficult to test in isolation.
4. Use interfaces over abstract classes. The exception would be when the method needs to be package-private (which Java does not allow for in interfaces).
5. Encapsulate. All fields should be of the smallest scope, and classes should be designed in a way that it is hard to use them incorrectly. See Airplane#update() for a good example of encapsulation. All the logic for the class should happen inside of it.
6. Avoid coupling. When it seems like you need to couple the GUI or the network to the game logic, use an observer instead. Similarly, do not poll, instead use the signal pattern. When something updates, notify the objects that need to respond to this update rather than constantly checking for changes.
7. Naming: use getXXX() for cached values (getter methods). Use an action verb like calculateXXX() or countXXX() if it is not cached but still an accessor method.