oofem-wiki

User Tools

Site Tools

Trace:
coding-conventions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
coding-conventions [2011/03/17 13:14] – mikael.ohmancoding-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 104: Line 105:
 </code> </code>
  
-Doxygen will inherit documentation from super classes, so do not add comments unless something specific needs to be said for the implementering routine. Be sure to document all variables and return value, even trivial ones, to avoid reporting errors when generating the documentation.+Again, Doxygen will inherit documentation from super classes, so do not add comments unless something specific needs to be said for the implementing routine. Be sure to document all variables and return value, even trivial ones, to avoid reporting errors when generating the documentation. Currently, OOFEM contains quite a large number of errors in the documentation and a convenient way to list all these errors is to separate the stderr output with the terminal command; 
 +<code> 
 + doxygen doc/refman/doxygen.cfg 2> dox_errors.txt 
 +</code>
  
 === Header file layout === === Header file layout ===
Line 132: Line 136:
 uncrustify -c oofem_dir/uncrustify.cfg --replace mysource.C uncrustify -c oofem_dir/uncrustify.cfg --replace mysource.C
 </code> </code>
-==== 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://www.oofem.org/resources/doc/extractorInput/html/extractorInput.html|Extractor Specification]] 
 + 
 +===== 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: <code>   * Test your implementation before committing. Run at least oofem basic tests and check the results: <code>
Line 139: Line 148:
 </code> </code>
   * Check if documentation is updated as well (includes not only doc++ comments, but also oofem documentation, that can be affected). Making it later usually means never.   * Check if documentation is updated as well (includes not only doc++ comments, but also oofem documentation, that can be affected). Making it later usually means never.
 +  * Make sure that new functionality comes with internal tests.
   * Please compile your sources with "-Wall", which will enable all the compiler warnings. Check compiler messages and clean up the code.     * Please compile your sources with "-Wall", which will enable all the compiler warnings. Check compiler messages and clean up the code.  
   * Reformat your code using uncrustify tool   * Reformat your code using uncrustify tool
coding-conventions.1300364070.txt.gz · Last modified: 2011/03/17 13:14 by mikael.ohman