[PATCH] Document conding style
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
Documentation/CodingGuidelines | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 3b042db..e1b5d78 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -77,6 +77,30 @@ For C programs:
of "else if" statements, it can make sense to add braces to
single line blocks.
+ - Avoid trailing whitespaces
+
+ - Pointer to struct foo type is (struct foo *), not (struct foo*)
+
+ - One space each around comparison operator "=="
+
+ - One space around assignment operator "="
+
+ - One space after "if", "while", "switch" and friends before "("
+
+ - No space between function name and "("
+
+ - A function without parameter is "static void foo(void)", not
+ "static void foo()"
+
+ - Don't do any declaration after a statement.
+
+ - Multi-line comment is:
+
+ /*
+ * This is multi line comment
+ * and this is its second line.
+ */
+
- Try to make your code understandable. You may put comments
in, but comments invariably tend to stale out when the code
they were describing changes. Often splitting a function
@@ -105,6 +129,9 @@ For C programs:
changed and discussed. Many git commands started out like
that, and a few are still scripts.
+ - Consider checking your patches with checkpatch from the linux
+ kernel. It helps you to spot trivial formating errors.
+
- Avoid introducing a new dependency into git. This means you
usually should stay away from scripting languages not already
used in the git core command set (unless your command is clearly
--
1.5.4.3.ga3d8