Revision as of 01:58, 27 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.
• Code layout. (ANSI is preferable)
• 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)
• Indentation to be of 4 SPACES, NOT Tab characters. (some editors have a feature which turns tab characters into spaces, like Code::Blocks)
• 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:

• GOTO's. (any sane programmer would not use these anyway)
• 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)

What you should strive for:

• Defensive and secure coding practices.
• Clarity of code.
• Maintain traditional naming conventions, for consistency.

See Also

• none

External Links

• tabs-vs-spaces