Coding Style (OpenXcom)

We use C++03 (not C++11, C++14, etc)

Naming

• In general, CamelCase, with words only separated by uppercases.
• ClassNames start with an uppercase.
• anyOther variable or method starts with a lowercase.
• _privateMembers start with an underscore.
• DEFINES_ENUMS_CONSTANTS are all uppercase with words separated by underscores.

Spacing

• In general, space things like you were writing a sentence. Don't let the code get squished up (eg. "a = 5 * b(4, 3) + -3 / 80" vs "a=5*b(4,3)+-3/80").
• Spaces after commas, semicolons, variables, operators, etc.
• No need for spaces after opening parenthesis.
• Use linebreaks to keep large unrelated blocks of code separate.
• Use tabs for indenting code blocks between brackets, one tab per level.

Readability

• Keep names nice and readable, specially if they're public, remember there's auto-complete. Abbreviations are ok occasionally.
• Short names are ok if it's just a minor variable or you'll be writing it a lot (eg. iterators called i, j, k).
• Use static consts for "magic numbers" that are hard to figure out on their own. Don't go replacing 0 with ZERO, but don't go leaving something like 8443.90438 either.
• Keep long operations intact if it improves readability, the compiler will automatically calculate them anyways. (eg. "margin = (60 + 2 * 12 + 25) / 2)" vs "margin = 54.5").
• Use comments to explain long boring code blocks.
• Use // for comments even if they're multi-line, it keeps them from getting in the way when you comment out code blocks with /* */.
• Split a comment into multiple lines if it gets too long. Same should apply to code, although I don't do it much.
• Avoid copy-pasting, avoid incredibly long code blocks, use spacing and comments and even more functions to keep everything neat.
• Keep the code clean, no useless includes, declarations, etc.

Documentation

• Doxygen is used for OpenXcom, with the convention of /// for single-line documentation, /** for multi-line documentation and @ for attributes (@param, @return, etc).
• Classes should have a multi-line description of their purpose in their header declaration.
• Methods should have a one-sentence brief description (///) in their header declaration and a multi-line full description (/**) in their definition.
• Don't forget to document method parameters and return values.
• Write in proper English. Please.
• Always end your sentences with a dot. This is usually not relevant for comments, but I think Doxygen uses these to better tidy up the stuff.
• Remember Doxygen will warn you about errors / missing documentation so run it from time to time.

Misc.

• In general, OOP conventions apply.
• Keep each class in its own equally-named header/source file. Keeping related enums/structs in the same file is fine.
• Always use brackets to start a block, even if it's just one line. Yes yes I know it's so many space wasted for one line, but eventually inevitably you'll slip up and forget to add them when you extend it. I know I have.
• Opening/closing brackets always lined up in their own lines.
• Keep variable declarations where relevant, don't leave them all at the start of code blocks ala ANSI-C, it makes it harder to tell their purpose.
• When declaring pointers, keep the * on the side of the variable name. This prevents common mistakes like "int* a, b, c" (only a will be a pointer).
• Feel free to put multiple declarations in one line.
• No need to check for null pointers when deleting stuff.
• Don't use NULL, it's not actually in the C++ standard and will be later replaced with nullptr by C++0x.
• Use iterators for looping through STL containers (vectors, maps, etc.).
• Use pre-increment/decrement (++i and --i) instead of post-increment/decrement (i++ and i--) except when it produces a different result.
• Use const on methods that don't change its class (eg. getter methods).
• Don't pass objects to functions by copy, use pointers or references (eg. "const std::string &s" instead of just "std::string s").
• Remember the C++ standard requires an empty linebreak on the end of every file.
• Avoid making generic utility classes or functions, keep everything in the class it's relevant to (make more classes if you have to, can never have enough!).
• Use common sense!