-
Notifications
You must be signed in to change notification settings - Fork 1
Coding Conventions
This follows a slightly modified version of the Java/Sun Coding Standards. It's "modified" because the version we are using is closer to the default version of the Eclipse formatter. These conventions include but are not limited to:
- Requiring comments for methods, classes, and packages in the proper Javadoc format.
- Requiring naming conventions such as constants being in all caps.
- Requiring packages to not use the "*" import and also making sure that all imports are used.
- Enforcing maximum file lengths, line lengths, and number of parameters.
- Requires there to be no tabs in the source code as well as enforcing other whitespace conventions that cause the code to be more readable.
- Requiring interfaces to have methods, and not just constants. It also checks that classes that only have private constructors are declared as final.
For more details on what the conventions are then please see the CheckStyle config file. It is located at the top of the repo at "./MetroBikeCheckStyle.xml"
We plan to enforce the coding conventions by verifying them during our code reviews. If the submitter has not followed the conventions then we will reject their code during the review. We are also providing a file for the Eclipse formatter so that they will only have to run the Eclipse format command on the code to take care of most of the style issues. Everything else they will have to do manually by finding the errors that the Eclipse CheckStyle plugin flags.
In order to help enforce our team's coding standards we will be using the Eclipse Checkstyle plugin (located at http://eclipse-cs.sourceforge.net/) which implements CheckStyle 5.6. We will also be using the Eclipse formatter. This enables to the team to quickly format the code to fix many of the errors that CheckStyle will throw. The file that contains the Eclipse Formatter settings is located at the top of the repo at "./MetroBikeEclipseFormatter.xml"
We plan on doing the code reviews by having one or more team members review code that is checked into the GitHub repository. We will annotate the code with feedback so that the customer can see that it has been reviewed. If we push new code to the repository we may ask one of our team members to review it (via email) so that it gets reviewed quickly and doesn't hold up the team. Each team member has an assigned code reviewer, though anyone is welcome to code review another teammate's code.