BOINC Coding Style Guideline

From Unofficial BOINC Wiki

[edit] General

This is a set of recommendations for Developers so that they can create code that is relatively consistent even though it is written by many different people. These guidelines have been developed to make the code look the same and to assist the Developer in making their code more secure.

[edit] Recommendations For All Languages

These guidelines should be used when writing code regardless of the portion of the system being changed, or the programming language in use.

[edit] 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
C++ .h files often contain both interface and implementation. Clearly divide these.

[edit] Code Documentation

every .C file has a comment at the top saying what's in the file (and perhaps what isn't). If a file is becoming 'landfill', split it up.
every function is preceded by a comment saying what it does
every struct/class is preceded by a comment saying what it is

[edit] Naming Conventions

Names should be descriptive without being verbose (local variables names may be short)
Class names, #defined symbols, and type names 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

[edit] 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;
        }

[edit] Constants

There should be few numeric constants in code. Generally they should be added and used as #defines. The name of a constant should indicate the use of the constant. Avoid the use of a name like: TWENTY_ONE, but use a name like: NUMBER_OF_SECTORS.

[edit] 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;

[edit] Comments and #ifdefs

use // for all comments
comment out blocks of code as follows:

        #if 0
            ...
        #endif

[edit] C++ Specific Guidelines

[edit] 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 go from general (<stdio.h>) to specific (thisfile.h)

[edit] extern Declarations

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

[edit] Use of Static

if a function or variable is used only in 1 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.

[edit] Error Codes

(almost) all functions should return an integer error code. Nonzero means error.
All 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;

[edit] Structure Definitions

Define structures as follows:

    struct FOO {
        ...
    };

You can then declare variables as:

    FOO x;

[edit] PHP Specific

[edit] Getting "POST" Data and/or "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.

[edit] UCB Source

BOINC coding style

2005 University of California
2005 Paul D. Buck

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.