Style Guidelines

1. No trailing whitespace (even on blank lines)
2. All indentation for code blocks are four spaces (no tabs)
3. Whenever a line is wrapped due to length, all lines subsequent to the first shall have a hanging indent of four spaces (no tabs).
4. No line shall be longer in length than 99 characters, except import statements, which shall be on a single line each.
5. Curly brackets for blocks shall begin on the same line containing the statement that started the block, and shall end on a new line (or the same line as a keyword delimiting a new block part of the same statement, e.g. else).
6. The first statement of a block in curly brackets shall begin on a new line.
7. All control-flow statements with nested blocks shall use curly brackets to delimit the blocks, unless the entire statement and all of its blocks can fit on a single line.
8. In between method declarations and inner class declarations in a class there shall be exactly one line of whitespace.
9. All fields in a class shall be at the top of the class, above any method declarations or constructors.
10. All constructors in a class shall be at the top of the class, immediately below any fields, but above any method declarations.
11. All fields that do not have javadocs shall be in a single block with no blank lines between them, or a set of logical blocks with a single blank line separating each block, and no blank lines within the block.
12. All fields with javadocs shall be separated from one another by a single blank line.
13. Blank lines shall be used inside functions only to separate logical portions of the function, and only one blank line at a time.
14. There shall be no use of "import .*" unless enumerating all the fields used in the class from that package would require enumerating the vast majority of the classes in the package, of which there are a significant number.
15. All classes used in a file from outside the package shall be imported rather than referenced with their fully qualified package path, unless to import them would cause an unavoidable namespace conflict.
16. New classes should endeavor at all costs to avoid possessing the same name as a common Java standard library class, or a class in another package of the repository. The only exceptions are classes where obeying this rule would force a completely unnatural class name.
17. Imports within a single top-level domain shall be in alphabetical order with no blank lines betwen them.
18. Imports from separate top-level domains shall have a single blank line to separate them.
19. Because the k framework is a part of the "org" top-level domain, "org" imports shall be on top, followed by all third-party top-level domains, followed by the java and javax top-level domains.
20. No public function shall have its functionality influenced by the value of a non-constant static variable. Thus, all static variables must either be declared final and initialized to an immutable type, or else be private and only used for purposes which have no impact on the semantics of any public API (e.g. caching).
21. There shall be no public or protected static inner classes, and no inner class shall fail to be static unless it relies upon instance fields of its parent class. Thus, there are only two cases where inner classes are acceptable: the first is if it would be nontrivial to separate the class from its parent elegantly, because of its use of state from the parent class. The second is if the class is private, and therefore only exists to provide functionality to its parent class.
22. Any code which commits an implementation of functionality which is imperfect and designed to be fixed latter shall be commented with a TODO that provides your user alias. For example, if I make such a commit, I should add a comment beginning with "// TODO(DwightG):" and proceeding to explain what needs to eventually be modified about the code.
23. All comments to the extent that a particular change needs to be made at some point in the future shall be treated as instances of rule #22 and subject to its format guidelines.
24. No commit shall modify lines of code only for the purposes of fixing incorrect styles, unless the commit only modifies style and only modifies lines of code last modified by the person making the commit in the immediate recent past (i.e. if someone asks you to fix your style in a code review, you can, as long as you keep it in a separate commit from any other later changes you make). Use your best judgment in applications of this rule: the purpose is to avoid littering diffs with unnecessary changes, which has a negative effect on productivity and code quality. The point is not to prevent changes from being made as they are observed to be relevant to the change you are making, simply to prevent a substantial amount of style changes being introduced into a diff they have nothing in common with. If you make a mistake here, it's not a big deal. But repeated and flagrant violations of this rule will be severely frowned upon and may force us to develop stronger, more disciplinary policies toward code commits.