This page documents the best practices for software development which should be followed by the LARICS team.
Code reviews are important and we should all start doing them. Coding standards without code reviews are like a robot with no power: looks nice, but isn't really good for aything. First team to do a code review gets a free lunch from the rest of the lab :)
Every software project must have a README.md file, containing at least the following information:
Language-specific sections contain links to examples with README.md files and recommended documentation tools.
All C++ code should adhere to the https://github.com/larics/coding_standard/blob/master/CppCodingStyleGuidelines.md. It is short and concise and referes only to programming style.
The C++ coding style cheat sheet can be found at:
Useful in-depth references on recommended C++ programming practices can be found below:
Doxygen is the recommended tool for generating developer documentation (API reference) for C++ projects.
A simple and complete C++ project sample conforming to the LARICS C++ programming style can be found here
All Python code should adhere to PEP 8.
PyCharm produces warnings when code does not follow the PEP 8 guidelines. Educational version of PyCharm is available for free.
Sphinx is the recommended tool for documenting Python code.
A simple and complete Python project sample conforming to the LARICS Python programming style can be found here
Suggested Matlab style guides:
[ante] Please check if this can be used as is or needs to be adapted.
Most of the MATLAB code should run in Octave, barring some functions that are not implemented. To see whether MATLAB function is implemented in Octave (and in which Octave package), check Octave function list here. Octave syntax is less restrictive than MATLAB, which can cause problems when running Octave code in MATLAB (check differences here).
A simple and complete Matlab project sample conforming to the LARICS Matlab programming style can be found here
Style for writing CMakeLists.txt files
Develop a best practices/style guide for CMake
Guidelines for git commit messages style are at software:git#commit_message_style. The same page also contains a tutorial and some general guidelines on using git.
All software should be versioned according to the Semantic versioning rules.
Incorporate "Software development best pactices" page from the old Wiki here.