wiki:CodingStyle

Version 4 (modified by Nicolas, 17 years ago) (diff)

Use bullets even in sections with only one item. It's more consistent, and easier to read since it puts everything at the same indent level.

BOINC coding style

All languages

Code factoring

  • If code is repeated, factor it out and make it into a function.
  • If a function becomes longer than 100 lines or so, split it up.
  • If a file is becoming 'landfill', split it up.
  • C++ .h files often contain both interface and implementation. Clearly divide these.

Code documentation

  • .C files have a comment at the top saying what's in the file (and perhaps what isn't).
  • Functions are preceded by a comment saying what they do.
  • Structs and classes are preceded by a comment saying what they are.

Naming

  • Names should be descriptive without being verbose (local variables names may be short).
  • Class and type names, and #defined symbols, are all upper case, with underscores to separate words.
  • Variable and function names are all lower case, with underscores to separate words.
  • No mixed case names.

Indentation

  • Each level of indentation is 4 spaces (not a tab).
  • Multi-line function call:
    func(
        blah, blah, blah, blah, blah,
        blah, blah, blah, blah, blah
    );
    
  • switch statements: case labels are at same indent level as switch:
    switch (foo) {
    case 1:
        ...
        break;
    case 2:
        ...
        break;
    }
    

Constants

  • There should be few numeric constants in code. Generally they should be #defines.

Braces

  • Opening curly brace goes at end of line (not next line):
    if (foobar) {
        ...
    } else if (blah) {
        ...
    } else {
        ...
    }
    
  • Always use curly braces on multi-line if statements.
    if (foo)
        return blah;     // WRONG
    
  • 1-line if() statements are OK:
    if (foo) return blah;
    

Comments and #ifdefs

  • Use // for all comments.
  • Comment out blocks of code as follows:
    #if 0
        ...
    #endif
    

C++ specific

Includes

  • A .C file should have the minimum set of #includes to get that particular file to compile (e.g. the includes needed by foo.C should be in foo.C, not foo.h).
  • Includes should be ordered from general (<stdio.h>) to specific (thisfile.h).

Extern declarations

  • foo.h should have 'extern' declarations for all public functions and variables in foo.C There should be no 'extern' statements in .C files.

Use of static

  • If a function or variable is used in only one file, declare it static.

Things to avoid unless there's a truly compelling reason:

  • Inline functions.
  • Operator or function overloading.
  • Templates.

Things to avoid

  • Use typedef (not #define) to define types.
  • Don't use memset() or memcpy() to initialize or copy classes that are non-C compatible. Write a default constructor and a copy constructor.

Error codes

  • (Almost) all functions should return an integer error code. Nonzero means error. See lib/errornumbers.h for a list of error codes.
  • Calls to functions that return an error code should check the code. Generally they should return on error, e.g.:
    retval = blah();
    if (retval) return retval;
    

Structure definitions

struct FOO {
    ...
};

You can then declare variables as:

FOO x;

PHP specific

Getting POST and GET data

Remember that hackers can pass arbitrary values in POST and GET, and they can use this to do SQL injections and other exploits.

  • Do not access $_POST or $_GET directly.
  • Use get_int(), get_str(), post_int() and post_str() (from util.inc) to get POST and GET data.
  • If a POST or GET value will be used in a SQL query, use process_user_text() to escape it.