doc/coding_style.dox
author klao
Wed, 15 Sep 2004 14:25:44 +0000
changeset 858 acc83957ee4a
parent 667 9cba4444d804
child 921 818510fa3d99
permissions -rw-r--r--
Handling strings with std::string
Do not segfault if srcdir env. variable is not set.
     1 /*!
     2 
     3 \page coding_style Hugo Coding Style 
     4 
     5 \section naming_conv Naming Conventions
     6 
     7 In order to make development easier we have made some conventions
     8 according to coding style. These include names of types, classes,
     9 functions, variables, constants and exceptions. If these conventions
    10 are met in one's code then it is easier to read and maintain
    11 it. Please comply with these conventions if you want to contribute
    12 developing Hugo library.
    13 
    14 \subsection cs-class Classes and other types
    15 
    16 The name of a class or any type should look like the following:
    17 
    18 \code
    19 AllWordsCapitalizedWithoutUnderscores 
    20 \endcode
    21 
    22 \subsection cs-func Methods and other functions
    23 
    24 The name of a function should look like the following:
    25 
    26 \code
    27 firstWordLowerCaseRestCapitalizedWithoutUnderscores 
    28 \endcode
    29 
    30 \subsection cs-funcs Constants, Macros
    31 
    32 The names of constants and macros should look like the following:
    33 
    34 \code
    35 ALL_UPPER_CASE_WITH_UNDERSCORES 
    36 \endcode
    37 
    38 \subsection cs-loc-var Class and instance member variables, auto variables 
    39 
    40 The names of class and instance member variables and auto variables (=variables used locally in methods) should look like the following:
    41 
    42 \code
    43 all_lower_case_with_underscores 
    44 \endcode
    45 
    46 \subsection cs-excep Exceptions
    47 
    48 When writing exceptions please comply the following naming conventions:
    49 
    50 \code
    51 ClassNameEndsWithException
    52 \endcode
    53 
    54 \warning In some cases we diverge from these rules.
    55 This primary done because STL uses different naming convention and
    56 in certain cases
    57 it is beneficial to provide STL compatible interface.
    58 
    59 */