Revision as of 02:20, 27 December 2007

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 reasonable 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

External Links

• tabs-vs-spaces