doc/syntax: improve coding style rules

README.md

@@ -119,6 +119,10 @@ for scripting and interacting with the apis.
 
 You could also checkout the [radare2 book](http://maijin.gitbooks.io/radare2book/content/).
 
+# Coding Style
+
+Look at [doc/syntax.md](https://github.com/radare/radare2/blob/master/doc/syntax.md).
+
 # Webserver
 
 radare2 comes with an embedded webserver that serves a pure

doc/clang-format

@@ -8,12 +8,11 @@ IndentCaseLabels: false
 IndentFunctionDeclarationAfterType: false
 IndentWidth: 8
 UseTab: Always
-AllowShortIfStatementsOnASingleLine: false
 IndentCaseLabels: false
-ColumnLimit: 78
+ColumnLimit: 0
 BreakBeforeBraces: Attach
 BreakBeforeTernaryOperators: false
+AllowShortIfStatementsOnASingleLine: true
 AllowShortCaseLabelsOnASingleLine: true
 AllowShortFunctionsOnASingleLine: Inline
-# This requires LLVM > 3.5
-AllowShortBlocksOnASingleLine: true
+AllowShortLoopsOnASingleLine: true

doc/syntax

@@ -1,38 +0,0 @@
-Syntax coding style guidelines
-==============================
-
-I will try to not being a boring document like most of already available
-coding style guidelines ;) Here'r some rules:
-
-
-* Do not bypass 78 columns
-
-* Use tabs instead of space based indentation
-  - The code should be smart enought to do not bypass 78 columns
-    using 5 space indentation.
-
-* function opens brackets at next line
-* do/for/if/while open brackets at same line
-* Commas and keywords should be followed by a space. f.ex:
-  if (blabl)
-  foo(one, two);
-
-* Do not use C99 variable declaration
-  - This way we reduce the number of local variables per function
-    and it's easier to find which variables are used, where and so on.
-
-* Comments should be smart. Function names should be enought explicit
-  to not require a comment to explain what it does. If this is not
-  possible at all, we can still use a comment. But it is a bad idea
-  to relay on comment to make the code readable.
-
-* Use 'R_API' define to mark exportable methods
-
-* Try not using oneline comments '//'. Use /* */ instead
-* To comment out some code use #if 0 (...) #endif
-
-* Do not write ultra-large functions, split them into multiple or simplify
-  the algorithm, only external-copy-pasted-not-going-to-be-maintained code
-  can be accepted in this way (gnu code, external disassemblers, etc..)
-
-* See doc/vim for vimrc

doc/syntax.md

@@ -0,0 +1,109 @@
+Syntax coding style guidelines
+==============================
+
+* Tabs are used for indentation. They are 8 chars. In a switch statement, the
+  cases are indentend at the switch level.
+
+```
+switch(n) {
+case 1:
+case 2:
+default:
+}
+```
+
+* Lines should be at most 78 chars
+
+* Braces open on the same line as the for/while/if/else/function/etc. Closing
+  braces are put on a line of its own, except in the else of an if statement or
+  in a while of a do-while statement. Always use braces, except when you have
+  filtering conditions or error paths that can fit into a one-line statement.
+
+```
+if (a == b) {
+	...
+}
+
+if (a == b) {
+	...
+} else if (a > b) {
+	...
+}
+
+if (a == b)
+	do_something ();
+
+if (a == b)
+	do_something ();
+else
+	do_something_else ();
+
+if (a == b) {
+	...
+} else {
+	do_something_else ();
+}
+
+do {
+	do_something ();
+} while (cond);
+
+if (a == b) {
+	b = 3;
+}
+
+if (!ok) return R_FALSE;
+
+if (!buf) goto err_buf;
+```
+
+* In general, don't use goto. The goto statement only comes in handy when a
+  function exits from multiple locations and some common work such as cleanup
+  has to be done.  If there is no cleanup needed then just return directly.
+
+  Choose label names which say what the goto does or why the goto exists.  An
+  example of a good name could be "out_buffer:" if the goto frees "buffer".
+  Avoid using GW-BASIC names like "err1:" and "err2:".
+
+* Use early returns instead of if-else when you need to filter out some bad
+  value at the start of a function.
+
+```
+int check(RCore *c, int a, int b) {
+	if (!c) return R_FALSE;
+	if (a < 0 || b < 1) return R_FALSE;
+
+	... /* do something else */
+}
+```
+
+* Use a space after most of the keyword and around operators.
+
+```
+a = b + 3;
+a = (b << 3) * 5;
+```
+
+* Do not leave trailing whitespaces at the end of line
+
+* Do not use C99 variable declaration
+  - This way we reduce the number of local variables per function
+    and it's easier to find which variables are used, where and so on.
+
+* Comments should be smart. Function names should be enought explicit
+  to not require a comment to explain what it does. If this is not
+  possible at all, we can still use a comment. But it is a bad idea
+  to relay on comment to make the code readable.
+
+* Use 'R_API' define to mark exportable methods
+
+* Try not using oneline comments '//'. Use /* */ instead
+
+* If you *really* need to comment out some code, use #if 0 (...) #endif. In
+  general, don't comment out code because it makes the code less readable.
+
+* Do not write ultra-large functions, split them into multiple or simplify
+  the algorithm, only external-copy-pasted-not-going-to-be-maintained code
+  can be accepted in this way (gnu code, external disassemblers, etc..)
+
+* See doc/vim for vimrc