This document describes intended and preferred conventions for development and maintenance of the Redistricting a Region software product.
For example, no merge results in a non-buildable state or a buildable product that does not execute.
Architectural elements, tests, and implementation code match requirements associated with the current and previous versions of the product.
For example, tests and code for features identified for future versions are excluded from the project code base.
Tracing backward from tests reveals the requirement(s) that such tests verify in the product.
Tracing backward from code likewise reveals the requirement(s) that such code implements in the product.
For example, new code is not merged into the project code base prior to the existence of automated test code for that new code.
Tracing backward from the code reveals the tests used to verify the behavior of the code.
The intent is for code to be developed using a test-first methodology, in which automated tests are written prior to writing the implementation.
Tests associated with successful implementation remains in the code base as regression tests.
(Note: Test coverage tools may facilitate tracing forward from a test to code that the test is intended to verify.)
Project-specific conventions take precedence.
If no project-specific convention is applicable, use the Sun Convention guide.
If something is not covered in the project-specific or the Sun Convention guide, use the Google Convention guide.
If a topic is not covered by any guides, use best judgement and consider opening a project issue to formalize the decision.
- Sun Convention guide: https://www.oracle.com/technetwork/java/codeconvtoc-136057.html
- Google Convention guide: https://google.github.io/styleguide/javaguide.html
- Multiple authors are indicated using multiple @author tags, one tag per line, one author per tag.
- Many style conventions are embodied in jp_checks.xml and jp_suppressions.xml configuration files for Checkstyle.