coding-conventions
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
coding-conventions [2011/01/05 03:03] – I'm so bold that i removed the part about $Id$ as it's not done, it doesn't seem necessary and noone seems to add it anyway. mikael.ohman | coding-conventions [2017/11/24 16:45] (current) – Add4d Documentation & Testing, updated Checks before commiting bp | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | =====Coding standard===== | ||
==== Naming conventions ==== | ==== Naming conventions ==== | ||
Line 41: | Line 42: | ||
==== Using comments to document the code ==== | ==== Using comments to document the code ==== | ||
OOFEM uses [[http:// | OOFEM uses [[http:// | ||
+ | |||
+ | If you are overloading methods from another class, you should **leave the documentation empty** and make sure the parameters are named exactly the same. Only write a new documentation field if you have something new to add specifically to the implemented methods. | ||
In general, a special comments should be added straight before each function, variable, class, define, etc. you wish to document. The simplest way is to add a simple comment with a short documentation string for the entry, e.g.: | In general, a special comments should be added straight before each function, variable, class, define, etc. you wish to document. The simplest way is to add a simple comment with a short documentation string for the entry, e.g.: | ||
Line 102: | Line 105: | ||
</ | </ | ||
- | Doxygen will inherit documentation from super classes, so do not add comments unless something specific needs to be said for the implementering | + | Again, |
+ | < | ||
+ | | ||
+ | </ | ||
=== Header file layout === | === Header file layout === | ||
Line 130: | Line 136: | ||
uncrustify -c oofem_dir/ | uncrustify -c oofem_dir/ | ||
</ | </ | ||
- | ==== Checks before committing ==== | + | ===== Documentation and Testing ===== |
+ | OOFEM aims to be high quality software and as a such it must be accompanied by high quality, up to date documentation. Also internal tests and benchmarks are absolutely necessary to ensure continuous software quality | ||
+ | * The new functionality (elements, material models, etc.) will be only accepted if relevant documentation will be provided, in particular the oofem manuals should describe the new functionality | ||
+ | * The new functionality will be only accepted if internal tests will be developed and documented. See existing tests in oofem distribution (tests directory), and [[http:// | ||
+ | |||
+ | ===== Checks before committing | ||
* For new work, commit only when some stage of implementation is reached and code is already useful. Do not use svn repository as daily backup tool for your files, that you are developing for several weeks. | * For new work, commit only when some stage of implementation is reached and code is already useful. Do not use svn repository as daily backup tool for your files, that you are developing for several weeks. | ||
* Test your implementation before committing. Run at least oofem basic tests and check the results: < | * Test your implementation before committing. Run at least oofem basic tests and check the results: < | ||
Line 137: | Line 148: | ||
</ | </ | ||
* Check if documentation is updated as well (includes not only doc++ comments, but also oofem documentation, | * Check if documentation is updated as well (includes not only doc++ comments, but also oofem documentation, | ||
+ | * Make sure that new functionality comes with internal tests. | ||
* Please compile your sources with " | * Please compile your sources with " | ||
* Reformat your code using uncrustify tool | * Reformat your code using uncrustify tool |
coding-conventions.txt · Last modified: 2017/11/24 16:45 by bp · Currently locked by: 3.138.204.208