Difference between revisions of "Coding standard"

From OdaWiki
(Requirements)
(Requirements)
Line 7: Line 7:
 
* Minimise the number of changes in each patch
 
* Minimise the number of changes in each patch
 
* Provide an off switch for every new feature
 
* Provide an off switch for every new feature
* Do not submit things you cannot test (e.g. alternative platforms)
+
* Do not submit things you cannot test (e.g. code for alternative platforms)
  
 
==Code guidelines==
 
==Code guidelines==

Revision as of 18:44, 22 May 2008

Overview

Odamex relies on a coding standard to ensure continuity, this reduces bugs and provides easy readability of the code.

Requirements

  • Make logical changes in separate patches
  • Minimise the number of changes in each patch
  • Provide an off switch for every new feature
  • Do not submit things you cannot test (e.g. code for alternative platforms)

Code guidelines

  • Add a test for every change (or an explanation of why this is impossible)

Things you should definitely AVOID in your code:

  • Changing code that already works
  • 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


External Links