Difference between revisions of "Coding standard"
From OdaWiki
Line 2: | Line 2: | ||
Odamex relies on a coding standard to ensure continuity, this reduces bugs and provides easy readability of the code. | Odamex relies on a coding standard to ensure continuity, this reduces bugs and provides easy readability of the code. | ||
− | =Requirements= | + | ==Requirements== |
* Add a [[test]] for every change | * Add a [[test]] for every change | ||
Line 8: | Line 8: | ||
* Make logical changes in separate patches | * Make logical changes in separate patches | ||
− | + | ==Code guidelines== | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | ==Code== | + | |
Things you should definitely AVOID in your code: | Things you should definitely AVOID in your code: | ||
Line 30: | Line 18: | ||
* C style strings. (replace them with C++ types where it is safe to do so) | * C style strings. (replace them with C++ types where it is safe to do so) | ||
* goto | * goto | ||
+ | |||
+ | ==Formatting guidelines== | ||
+ | |||
+ | * If creating a new file, include a GPL header at the top of it, as seen in other files. | ||
+ | * Descriptive comments | ||
+ | * Comments of reasonable size. (not too big and not too small) | ||
+ | * Comment formatting. (in c/c++, either // for 1 liners or /* */ for multiple lines) | ||
+ | * Indentations to be of 1 tab character, using 4 space width tabs | ||
+ | * Be sure your editor/IDE's EOL mode is LF, not CRLF or CR | ||
+ | * 80 line character limit, for devs with text-based editors | ||
+ | * if you can, limit functions to a maximum size (like the amount that would fit on a monitor with a reasonable screen resolution) | ||
What you should strive for: | What you should strive for: |
Revision as of 14:16, 5 May 2008
Contents
Overview
Odamex relies on a coding standard to ensure continuity, this reduces bugs and provides easy readability of the code.
Requirements
- Add a test for every change
- Do not fix code that already works
- Make logical changes in separate patches
Code guidelines
Things you should definitely AVOID in your code:
- Precompiler macros
- Global variables (they can create problems elsewhere in code)
- Variants (tagged unions) - they can present a performance problem
- Magic numbers (use #define or const in your code for fixed numbers, at the top of files)
- Hungarian notation (just plan evil)
- C style strings. (replace them with C++ types where it is safe to do so)
- goto
Formatting guidelines
- If creating a new file, include a GPL header at the top of it, as seen in other files.
- Descriptive comments
- Comments of reasonable size. (not too big and not too small)
- Comment formatting. (in c/c++, either // for 1 liners or /* */ for multiple lines)
- Indentations to be of 1 tab character, using 4 space width tabs
- Be sure your editor/IDE's EOL mode is LF, not CRLF or CR
- 80 line character limit, for devs with text-based editors
- if you can, limit functions to a maximum size (like the amount that would fit on a monitor with a reasonable screen resolution)
What you should strive for:
- Clarity of code
- Defensive and secure coding practices
- Maintain traditional naming conventions, for consistency
See Also
- none