Math - Developers Guide

Aims

Creating and maintaining a mathematical and statistical library that is accurate requires a greater degree of communication than might be the case for other components. It is important that developers follow guidelines laid down by the community to ensure that the code they create can be successfully maintained by others.

Guidelines

Developers are asked to comply with the following development guidelines. Code that does not comply with the guidelines including the word must will not be committed. Our aim will be to fix all of the exceptions to the "should" guidelines prior to a release.

Contributing

Here are some steps to take to get starting contributing to commons-math:

Start by reviewing the overall objectives stated in the proposal upon which the project is founded.
Review the completed, current and future tasks of the project. Also have a look at the Wiki.
Be sure to join the commons-dev and commons-user email lists and use them appropriately (make sure the string "[math]" starts the Subject line of all your postings). Make any proposals here where the group can comment on them.
Setup an account on Bugzilla and use it to submit patches and identify bugs. Read the directions for submitting bugs and search the database to determine if an issue exists or has already been dealt with.
Submitting Issues:
- Bookmarkable Template for submitting patches.
- Bookmarkable Template for submitting bugs.
Querying the Database:
- New and Existing Issues.
- Resolved and Closed Issues.
Generating patches: The requested format for generating patches is the Unified Diff format, which can be easily generated using the cvs client or Eclipse IDE.
```
					cvs diff -u > patch
				
```

Coding Style

Commons-math follows Code Conventions for the Java Programming Language . As part of the maven build process, style checking is performed using the Checkstyle plugin, using the properties specified in checkstyle.xml. Committed code should generate no Checkstyle errors.

Documentation

Committed code must include full javadoc.
All component contracts must be fully specified in the javadoc class, interface or method comments, including specification of acceptable ranges of values, exceptions or special return values.
External references or full statements of definitions for all mathematical terms used in component documentation must be provided.
Implementations should use standard algorithms and references or full descriptions of all algorithms should be provided.

Unit Tests

Committed code must include unit tests.
Unit tests should provide full path coverage.
Unit tests should verify all boundary conditions specified in interface contracts, including verification that exceptions are thrown or special values (e.g. Double.NaN, Double.Infinity) are returned as expected.

Licensing and copyright

All new source file submissions must include the Apache Software License in a comment that begins the file
All contributions must comply with the terms of the Apache Contributor License Agreement (CLA)
Patches must be accompanied by a clear reference to a "source" - if code has been "ported" from another language, clearly state the source of the original implementation. If the "expression" of a given algorithm is derivative, please note the original source (textbook, paper, etc.).
References to source materials covered by restrictive proprietary licenses should be avoided.