• CodingGuidelines

Coding Guidelines

• This page is from the old wiki

This page is meant to describe the development aspects of DOMS. Further sections may be added as we need them.

Development model

We are using the develoment model "Evolutionary Prototyping".

This will split our work up into small iterations, each ending up in a functional protytpe, which can be tested against that iterations accepted goals.

Each iteration should last no longer than 2-3 weeks, and should follow these approximate steps:

1. Choice of objectives for this iteration. Definition and manning of work pacakges for this iteration. Done in collaboration. 1 day.
2. Description of work packages. One work package is always release test. 1-2 days.
3. Implementation of work packages. 4-6 days.
4. Release test.

Thus each work package is pretty small. However, bugs and design errors are caught quickly, and redesiging during the project is fairly efficient.

Code style

This has been moved to CodeStyle.

Licensing

We develop code under the LGPL. Although there are currently no public releases, please observe the following guideline:

• Each source file should contain the LGPL header in a comment in the top.

Documentation

Every public method must hava javadoc. Best Practice is writing javadoc before the method, thus deciding on design before implementation. Javadoc'ing private methods is encouraged for non-trivial methods. Javadoc should be written in English.

External Libraries

Use of third-party external libraries is fine. Please add the library in the "lib"-directory of the module you use it in, or in the top level "lib"-directory for global libraries. Please add the library to the libraries used in the project page, with version number and license information.

Logging

Logging is done using Log4J. Please reserve the logging level "fatal" for non-recoverable errors. Please log in English.

Languages and Resource Bundles

For internal use, please use English. That is messages in logging, exceptions etc. are in English.

For end-user strings, please use a resource bundle. There is a guide to our use of resource bundles.

Unit tests

Unit tests are encouraged on all non-trivial methods.

A good unit test:

• Tests only the method its written for, use mockups for surroundings
• Tests all situations described in javadoc
• Tests borderline cases

CVS

Please commit at least once a day.

Please do not commit non-compiling code.

Please run unit tests before committing, and make sure you haven't broken previous behaviour.