JavaScript Restrictor
Browser extension that improves privacy and security
Loading...
Searching...
No Matches
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.
  • Parameters
    abcThe 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.