Introduction
Development guidelines are written here to help CAS developers maintain consistency and quality in the source that we write. The product is Java source code or artifact resources. Stiff process is not required, however guidelines are helpful in the act of quality compliance. Software among team members should reflect no individual authorship. These guidelines will help with this goal.
Analysis and Requirements
Requirements for this release will generally be very dynamic due to multiple customer (university) needs. The requirements should be clearly documented, however readers should accept that they may change throughout the life of the release cycle. Analysis may not be so public but actionable requirements will be drafted and maintained in this Confluence space.
Development
CAS development has been managed using the Apache Maven product. Maven can be used to create Eclipse project files to complement the SVN checkout. We recommend that the Eclipse IDE is used during this development cycle. If Eclipse can be approved by the CAS Steering Committee, it would provide a common IDE and allow the use of new file templates. This would do an excellent job of maintaining a quality source format and consistency.
Coding Standards
Java coding standards should follow the guidelines set forth by Sun Microsystems. These guidelines are titled Code Conventions for the Java Programming Language and found here. Other clarifications should be noted in addition to those found above.
...
These recommendations are rules of thumb and may not be followed in all cases. They are here for guidance only.
Formatting and Templates
It is recommended that the development team adopt a template if e.g. Eclipse were used for development. IDE is not too important, but the code that we write should be formatted in the same manner. Tabs should not be allowed. And during code reviews they should be removed if found.
...
Code Reviews
After source files are checked in, periodic code reviews should be done as a group or peer-to-peer as development begins. Depending on the skill level of the team members, group or peer-to-peer should be chosen. Code reviews are necessary and should not be avoided.
Testing
All classes and methods should have corresponding JUnit tests. JavaBeans are exempt. If team members were to pick and choose what is tested, quality will suffer.