diff options
| -rw-r--r-- | firmware/CONTRIBUTING | 43 |
1 files changed, 33 insertions, 10 deletions
diff --git a/firmware/CONTRIBUTING b/firmware/CONTRIBUTING index 73f124eb7b..dce0227d25 100644 --- a/firmware/CONTRIBUTING +++ b/firmware/CONTRIBUTING @@ -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. +Language +-------- +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". +Language features +----------------- +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. +Names +----- +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. +Style +----- +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. + +Text format +----------- +Use "unix style" line feeds: "LF" only. Do not use "CR+LF". + +Patches +------- +Create a patch using 'cvs diff -ub'. Trim your patches so they only contain +relevant changes. +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. |