1 files changed, 33 insertions, 10 deletions
diff --git a/firmware/CONTRIBUTING b/firmware/CONTRIBUTING
index 73f124eb7b..dce0227d25 100644
@@ -3,17 +3,40 @@ $Id$
In order for the project to run as smoothly as possible, it's best if all
contributors adhere to a few simple conventions:
-- Write all code in C. Sometimes assembly is faster, but C is always more
- readable and maintainable.
+Write all code in C. Sometimes assembly is faster, but C is always more
+readable and maintainable.
-- Write normal C code. Don't redefine the language. No new types,
- no C++isms or Javaisms. Also, do not use "const".
+Write normal C code. Don't redefine the language. No new types (structs are
+structs, not typedefs), no C++isms or Javaisms. Also, avoid using "const".
-- Variables and function names should be all lower case.
- Preprocessor symbols should be all uppercase.
+Variables and function names should be all lower case.
+Preprocessor symbols should be all uppercase.
-- Use the brace placement style of your choice, but indent your code with
- four spaces. Don't use TAB characters, as that will mess up code display in
- CVS, printing, and a zillion other places.
+When changing code, follow the code style of the file you are editing.
-- Use "unix style" line feeds: "LF" only. Do not use "CR+LF".
+When writing new files, you may use the brace placement style of your choice.
+Always indent your code with four spaces. Don't use TAB characters, as that
+will mess up code display in CVS, printing, and a zillion other places.
+Keep lines below 80 columns length. Use whitespace and newlines to make the
+code easy to browse/read.
+Use "unix style" line feeds: "LF" only. Do not use "CR+LF".
+Create a patch using 'cvs diff -ub'. Trim your patches so they only contain
+Submit all patches to the mailing list. Put [PATCH] first on the subject line
+of your mail. If the patch is very large (>50k), gzip it before you send it.