Coding Conventions

Coding conventions are a preferred way of doing things.

Files

• Although Grails can handle both dos (\r\n) and *nix (\r) line ends *nix is preferred.
• It is project policy not to include developer's names in the source files, recognition will be given in better and more visible ways.

Format

• Please set-up your IDE or editor to use a indent of 4 spaces, with no tabs.
• Follow the generally used formatting of code you see in Grails and the project.

Grails

• As much as possible try to keep the CRUD pages as generated by "grails generate-all"
• For example the Task views and controller are retained as is for application administration.
• If we want to modify the Task views and controller:
  • Create a copy of the whole views folder called TaskDetailed/show.gsp etc
  • Create a copy of the controller called TaskDetailedController.groovy and edit the class inside to match.
  • Then detail to your hearts content.

This way the original views are available as direct access to the data for administration. If the domain changes enough a "grails generate-all" can be performed on most domains without losing the customisations.

Proposed suffix 'Detailed as in detailing a car, customised or air-brushed, unless a better suffix is suggested.

A notable exception to this is Person and Authority use 'svn revert' if you accidentally regenerate these.

Documentation

The documentation is along side the source for good reason they need to be kept in sync. Document and code simultaneously. If you code a feature, document it as you go or better still design the feature by using the documentation then code and document as you go. This way the two are really not that different. Use self documenting code, don't abbreviate: LinIntDist could mean a lot of things LinthianInternalDistortion is a lot more clear.