Adding a HACKING file with some basic rules of styling and code formatting.
authorMichael Dominic Kostrzewa <michael.kostrzewa@nokia.com>
Tue, 6 Feb 2007 10:17:33 +0000 (10:17 +0000)
committerMichael Dominic Kostrzewa <michael.kostrzewa@nokia.com>
Tue, 6 Feb 2007 10:17:33 +0000 (10:17 +0000)
ChangeLog.2
HACKING [new file with mode: 0644]

index 022666c..376272a 100644 (file)
@@ -1,5 +1,10 @@
 2007-02-06  Michael Dominic Kostrzewa  <michael.kostrzewa@nokia.com> 
 
+       * HACKING: Adding a HACKING file with some basic rules of styling and
+       code formatting.
+
+2007-02-06  Michael Dominic Kostrzewa  <michael.kostrzewa@nokia.com> 
+
        * src/hildon-color-button.c:
        * src/hildon-color-button.h: Updating documentation.
 
diff --git a/HACKING b/HACKING
new file mode 100644 (file)
index 0000000..b922257
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,29 @@
+The general rules of conduct are:
+
+* Code identation is 4 spaces NO TABS
+* Function parameters start at column 48, one param per line
+* Use inside-code gtk doc documentation for everything 
+* Do not put documentation outside of the code
+* Use g_assert's inside private functions where it makes sense (they're not
+  compiled-in by default)
+* Put space to separate operators. Ie:
+
+{
+    some_function (param1, param2);
+    a = 1 + 2;
+    b [1] = 10;
+}
+
+NEVER EVER DO:
+
+{
+    some_function(param1,param2);
+    a=1+2;
+    b[1]=10;
+}
+
+* Small testing programs can be put in the examples/ directory. They can be run
+  without installation blah blah blah blah blah blah blah blah  
+* Obey the rules present in the existing code base -- it's pretty consistent
+* Use ONE blank line to separate things 
+