From fde18d640b65748ab564ce736e1c7865337d1265 Mon Sep 17 00:00:00 2001
From: Libor Polčák <ipolcak@fit.vutbr.cz>
Date: Jun 12 2020 14:57:13 +0000
Subject: Provide CODING_STYLE rules


---

diff --git a/CODING_STYLE b/CODING_STYLE
new file mode 100644
index 0000000..43aebad
--- /dev/null
+++ b/CODING_STYLE
@@ -0,0 +1,65 @@
+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.