Difference between revisions of "Coding standard"
From OdaWiki
(→Formatting) |
(→Code) |
||
| Line 28: | Line 28: | ||
Things you should definitely AVOID in your code: | Things you should definitely AVOID in your code: | ||
| − | * | + | * Precompiler macros |
| − | + | * Global variables (they can create problems elsewhere in code) | |
| − | * Global variables | + | * Variants (tagged unions) - they can present a performance problem |
| − | * Variants | + | * Magic numbers (use #define or const in your code for fixed numbers, at the top of files) |
| − | * Magic numbers | + | * Hungarian notation (just plan evil) |
| − | * Hungarian notation | + | |
* 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 | ||
What you should strive for: | What you should strive for: | ||
| − | * Defensive and secure coding practices | + | * Clarity of code |
| − | + | * Defensive and secure coding practices | |
| − | * Maintain traditional naming conventions, for consistency | + | * Maintain traditional naming conventions, for consistency |
==See Also== | ==See Also== | ||
Revision as of 01:27, 31 October 2006
Overview
Odamex relies on a coding standard to help keep consistency between subprojects, this also helps things like reduce bugs and also provides easy readability of the code.
Some of the existing doom code in Odamex breaks these guidelines, which is exempt, unless you want to rewrite it!
General Requirements
This is a list of general things that must be adhered to when you are:
- An Odamex developer.
- A patch submitter.
Rules:
- Do not break code, if it works, leave it, if it doesn't, fix it!
- Do not change formatting of code.
Formatting
- 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 reasonably screen resolution)
Code
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
What you should strive for:
- Clarity of code
- Defensive and secure coding practices
- Maintain traditional naming conventions, for consistency
See Also
- none