= 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.
 1. Description of work packages. One work package is always release test. 1-2 days.
 1. Implementation of work packages. 4-6 days.
 1. 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 [[http://www.gnu.org/copyleft/lesser.html|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 [[ResourceBundles|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.