CODING_STYLE

Indentation: tabulators
Avoid spaces/tabs at the end of the line

Functions, methods, classes, ifs, cycles etc. have opening braces at the same line.

Text width preferred less than 80 characters, maximum 100 characters. It is better having readable
code than pursuing this limit.

Always enclose blocks of expressions into brackets.

Names are lower case and prefferably explains the purpose of the variable, class etc.

Comment classes, functions, etc. in Doxygen style, use 'make doc' to generate documentation.

Correct code example:

/**
 * This is an example function created for the coding style manual.
 * 
 * @param abc The number that will be ...
 * @returns  The Answer to the Ultimate Question of Life, The Universe, and Everything.
 */
function example(abc) {
	var counter = 0;
	for (let i = 0; i < 42; i++) {
		counter++;
	}
	return counter;
};

Bad code example:

function example(abc)
{
    function method()
    {
      return 42;
	  }
  	return method();
};

However, please do not provide commits dealing with bad coding style. The only exception is if you
want to improve code that does not follow the coding style rules. Preferably provide one commit that
fixes the issues and another (others) that improve the code, add new functionality etc.


Create atomic commits, see for example, https://www.freshconsulting.com/atomic-commits/

A commit should not contain adding missing semicolons, changes in generated code, a bugfix, and
addition of a new functionality. Each of these changes should go to a separate commit with a message
explaining why is the change necessary (if it is not obvious like in the case of missing
semicolons).

Provide meaningful commit messages, see, for example, https://chris.beams.io/posts/git-commit/,
especially points 1, 2 a 7.

Do not fear of changing commits that are not public, yet. If you create a bug and find it before
merge, it is better to fix the bug in the original commit. See `git rebase (-i)`, fixup, squash,
`git push --force`.

The pull request #39 contains an example of big commits that needed to be refactored.

Provide merge request more often rather than commiting big changes. If you fix Makefile or other
scripts, provide the change and do not wait. Create code that is understandable and does not repeat
itself. If possible, use variables instead of copying the same code.