From SOFAWiki

Contents 1 Generic coding Rules 2 Good Behavior 3 Sofa specific rules 4 Documentation rules 5 Version Control Rules

Generic coding Rules

A must requirement must be followed, a should is a strong recommendation, and a "can" is a general guideline.

1. Tricky code should not be commented but rewritten! In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure
2. All comments must be written in English. In an international environment English is the preferred language
3. All definitions should reside in source files. The header files should declare an interface only
4. Special characters like TAB and page break must be avoided
5. The use of magic numbers in the code should be avoided. Numbers other than 0 and 1 should be considered declared as named constants instead

Good Behavior

Sofa is a big collaborative project involving lots of developers. A modification of the code can have consequences to other developers.

1. After EACH commit you make, you must watch the Sofa Dashboard. It is YOUR responsibility to make sure Sofa continues to compile and work on all the platform (Linux, Windows, Mac) tested. If you need help, feel free to ask for some on our IRC channel for developers.
2. You must take care of not adding any warning during compilation on all the platforms
3. You must check that default Sofa scene still runs correctly and that you did not add any WARNING during execution (like CODE WARNING: MISSING SOFA_CLASS, for example).

Sofa specific rules

1. All the code under development must be tagged SOFA_DEV
2. All internal data, needed by your component, and that can't be recomputed must be put inside a Data or a DataPtr. Like this, your component can be saved. Indeed, this Data will be automatically displayed inside the GUI
3. Use sout, serr, sendl instead of cout, cerr, endl in Sofa Components.
   • serr will automatically display inside the console a message with a warning, the name of the component, and its class. If you modify the component in the graph, you will see a tabulation named "Warnings" with the log of all the serr done by the component
   • sout will display inside the console a message ONLY if the Data f_printLog is set to true. IIf you modify the component in the graph, you will see a tabulation named "Outputs" with the log of all the sout done by the component
4. Use sofa::helper::vector, sofa::helper::set instead of std::vector, std::set
5. Only use sofa::simulation::tree::GNode when you need to directly use access to the children or the parent of the node. If not, use the more generic sofa::simulation::Node

Documentation rules

1. A small description for each component must be provided, when it is added to the factory
2. An example showing the behavior of each component must be provided, and placed in examples/Components/. This xml file must have the exact same name as the component

Version Control Rules

1. All commits must have a log message describing the modification
2. Each commit should contain only one logical modification
3. Mixing indentation and logical modifications in a same commit should be avoided
4. All commits must starts with:
   • ADD: New files or new functionality
   • CHANGE: General modifications
   • FIX: bug fix on a given component
   • CRITICAL BUG: bug touching the entire system
5. Changes on the sofa::core must be preceded by WARNING (ADD|CHANGE|FIX)