Changes between Initial Version and Version 1 of CodingStyle


Ignore:
Timestamp:
Apr 25, 2007, 12:29:51 PM (17 years ago)
Author:
Nicolas
Comment:

Converted by an automatic script

Legend:

Unmodified
Added
Removed
Modified
  • CodingStyle

    v1 v1  
     1= BOINC coding style =
     2
     3
     4==  All languages ==
     5
     6===  Code factoring ===
     7
     8 * If code is repeated, factor it out and make it into a function
     9 * If a function becomes longer than 100 lines or so, split it up
     10 * If a file is becoming 'landfill', split it up.
     11 * C++ .h files often contain both interface and implementation.         Clearly divide these.
     12
     13
     14===  Code documentation ===
     15
     16 * .C files have a comment at the top saying what's         in the file (and perhaps what isn't).
     17 * Functions are preceded by a comment saying what they do.
     18 * Structs and classes are preceded by a comment saying what they are.
     19
     20
     21===  Naming ===
     22
     23 * Names should be descriptive without being verbose         (local variables names may be short)
     24 * Class and type names, and #defined symbols, are all upper case,         with underscores to separate words.
     25 * Variable and function names are all lower case,         with underscores to separate words.
     26 * No mixed case names
     27
     28
     29===  Indentation ===
     30
     31 * Each level of indentation is 4 spaces (not a tab).
     32 * multi-line function call:
     33{{{
     34        func(
     35            blah, blah, blah, blah, blah,
     36            blah, blah, blah, blah, blah
     37        );
     38        }}}
     39 * switch statements: case labels are at same indent level as switch
     40{{{
     41        switch (foo) {
     42        case 1:
     43            ...
     44            break;
     45        case 2:
     46            ...
     47            break;
     48        }
     49        }}}
     50
     51
     52===  Constants ===
     53
     54
     55
     56===  Braces ===
     57
     58 * Opening curly brace goes at end of line (not next line):
     59{{{
     60        if (foobar) {
     61            ...
     62        } else if (blah) {
     63            ...
     64        } else {
     65            ...
     66        }
     67    }}}
     68 * always use curly braces on multi-line if statements
     69{{{
     70        if (foo)
     71            return blah;        // WRONG
     72    }}}
     73 * 1-line if() statments are OK:
     74{{{
     75        if (foo) return blah;
     76    }}}
     77
     78
     79===  comments and #ifdefs ===
     80
     81 * use // for all comments
     82 * comment out blocks of code as follows:
     83{{{
     84        #if 0
     85            ...
     86        #endif
     87    }}}
     88
     89
     90==  C++ specific ==
     91
     92===  Includes ===
     93
     94 * 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)
     95 * Includes should go from general (<stdio.h>) to specific (thisfile.h)
     96
     97
     98===  extern declarations ===
     99
     100
     101
     102===  Use of static ===
     103
     104 * if a function or variable is used only in 1 file, declare it static.
     105
     106
     107===  Things to avoid unless there's a truly compelling reason: ===
     108
     109 * inline functions
     110 * operator or function overloading
     111 * templates
     112
     113
     114===  Things to avoid ===
     115
     116 * use typedef (not #define) to define types
     117 * don't use memset() or memcpy() to initialize or copy classes         that are non-C compatible.         Write a default constructor and a copy constructor.
     118
     119
     120===  error codes ===
     121
     122 * (almost) all functions should return an integer error code.         Nonzero means error.         See lib/errornumbers.h for a list of error codes.
     123 * Calls to functions that return an error code should         check the code.         Generally they should return on error, e.g.:
     124{{{
     125            retval = blah();
     126            if (retval) return retval;
     127    }}}
     128
     129
     130===  structure definitions ===
     131
     132
     133
     134{{{
     135
     136    struct FOO {
     137        ...
     138    };
     139    }}}
     140      You can then declare variables as:
     141{{{
     142    FOO x;
     143    }}}
     144
     145==  PHP specific ==
     146
     147=== Getting POST and GET data ===
     148 Remember that hackers can pass arbitrary values in POST and GET, and they can use this to do SQL injections and other exploits.
     149 * Do not access $_POST or $_GET directly.
     150 * Use get_int(), get_str(), post_int() and post_str()     (from util.inc) to get POST and GET data.
     151 * If a POST or GET value will be used in a SQL query,     use process_user_text() to escape it.
     152