User Tools

Site Tools


software:coding_standard

LARICS coding standards

This page documents the best practices for software development which should be followed by the LARICS team.

Code reviews

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 :)

Code documentation standards

Every software project must have a README.md file, containing at least the following information:

  • short summary of the project
  • intended hadware and software platform(s)
  • list of prerequisites
  • instructions for compiling the code
  • instructions for running the code
  • instructions for compiling and viewing the documentation

Language-specific sections contain links to examples with README.md files and recommended documentation tools.

C++ coding style

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

  • [goran]In addition to programming style, we should also have a document outlining LARICS recommended practices for C++ programming as a template, we can use geosoft.no C++ programming practices

Python coding style

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

  • [marsela] Complete the plain Python example.
  • [damjan] Review the plain Python example.

ROS coding style

ROS C++ coding style

  • [tomislav]Provide a ROS C++ sample
  • [juraj]Review the ROS C++ sample

ROS Python coding style

  • [matko]Provide a sample ROS Python
  • [barbara]Review the ROS Python sample

C/embedded coding style

  • ?

C# style

  • [edin]Provide a C# example
  • [matko]Review the C# example

Qt style

  • Provide a Qt example
  • Review Qt example

Matlab style

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

  • [ante] Please provide the Matlab/Octave example
  • [frano] Review the Matlab/Octave example

CMake style

Style for writing CMakeLists.txt files

[antun]Develop a best practices/style guide for CMake

LaTeX style

Git style

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.

Continuous integration

Releasing software

All software should be versioned according to the Semantic versioning rules.

Test-driven develpment

  • ?

[damjan] Incorporate "Software development best pactices" page from the old Wiki here.

Instructions for final theses and master's theses

software/coding_standard.txt · Last modified: 2017/07/18 00:34 by rmilijas