Changes between Version 6 and Version 7 of StyleGuide

Timestamp:

Feb 28, 2014, 7:19:08 AM (10 years ago)

Author:

MarkDoliner

Comment:

Small improvements

StyleGuide

@@ -1 @@
-= Coding Standards =
+= Code Style Guide =
 
-We try to follow K&R coding style in most of our code.  Some existing code violates these standards.  If you are writing a patch against some such code, please do fix violations in that block of code – but don't reformat entire files!
+Please follow these guidelines when writing new code in Pidgin, Finch, and libpurple. If you are writing a patch against code that violates these standards, please fix violations in that block of code – but don't reformat entire files!
 
-Here are some examples to help explain the intended style:
+In general we try to follow K&R coding style in most of our code. See below for specific examples:
+
 
 == Braces ==
- * Braces start at the same line as the if/while/do/for block
- * End braces are on their own lines, indented to the starting of the
- block, e.g.:
+ * Prefer braces around single line blocks. Reasons:
+   * Reduces chances of bugs, if someone adds code at the same indentation level without realizing that there are no braces.
+   * Smaller diffs when adding code to an existing single-line block.
+ * For functions, structs, typedefs, etc. braces start on their own lines.
+ * For if, while, do, for, etc. braces start on the same line.
+ * Braces end on their own lines, indented equally as the start of the
+ block.
+
 {{{
 #!c
-for (i = 0; i < x; i++) {
-        /* the code here, indented by a tab */
-}
-}}}
- * The starting braces for functions, structs etc. are on their own lines e.g.:
-{{{
-#!c
-struct _somestruct
+static void
+some_function(int x, int y)
 {
-        /* stuff */
+        if (x > y) {
+            return;
+        }
+
+        for (i = 0; i < x; i++) {
+                /* the code here, indented by a tab */
+        }
 };
 }}}
 
+
 == Indentation ==
- * We use tab for indentation (and it's preferable that you use 8-space tabs in your editor)
+ * We use tab for indentation (and it's preferable that you use 8-space tabs in your editor).
+ * When wrapping long lines, tab indent to the start of the statement then add two more tabs.
 
 
@@ -38 +46 @@
 }}}
  * No whitespace at the end of line
+
 
 == Comments ==
@@ -55 +64 @@
 }}}
 
+
 == Function Definitions ==
-
  * There should be a newline between the return type of the function and the function's name.
  * Wrap parameters sensibly, preferably around 80 characters or so.
@@ -70 +79 @@
         /* misc, other */
 }
+
+
+== Variable Declarations ==
+ * Prefer declaring each variable on its own line. This makes diffs easier to read and reduces churn.
+ * Use const for variables that don't need to change or be deallocated.