coding-standard.tex 6.48 KB
 Chris Cantwell committed Aug 08, 2014 1 \chapter{Coding Standard}  Chris Cantwell committed Oct 09, 2014 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145  The purpose of this page is to detail the coding standards of the project which all contributers are requested to follow. This page describes the coding style standard for C++. A coding style standard defines the visual layout of source code. Presenting source code in a uniform fashion facilitates the use of code by different developers. In addition, following a standard prevents certain types of coding errors. All of the items below, unless otherwise noted, are guidelines. They are recommendations about how to lay out a given block of code. Use common sense and provide comments to describe any deviation from the standard. Sometimes, violating a guideline may actually improve readability. If you are working with code that does not follow the standard, bring the code up-to-date or follow the existing style. Don’t mix styles. \section{Code Layout} The aim here is to maximise readability on all platforms and editors. \begin{itemize} \item Code width of 80 characters maximum - hard-wrap longer lines. \item Use sensible wrapping for long statements in a way which maximises readability. \item Do not put multiple statements on the same line. \item Do not declare multiple variables on the same line. \item Provide a default value on all variable declarations. \item Enclose every program block (if, else, for, while, etc) in braces, even if empty or just a single line. \item Opening braces (\{) should be on their own line. \item Braces at same indentation as preceeding statement. \item One class per .cpp and .h file only, unless nested. \item Define member functions in the .cpp file in the same order as defined in the .h file. \item Templated classes defined and implemented in a single .hpp file. \item Do not put inline functions in the header file unless the function is trivial (e.g. accessor, empty destructor), or profiling explicitly suggests to. \item Inline functions should be declared within the class declaration but defined outside the class declaration at the bottom of the header file. \begin{notebox} Virtual and inline are mutually exclusive. Virtual functions should therefore be implemented in the .cpp file. \end{notebox} \end{itemize} \section{Space} Adding an appropriate amount of white space enhances readability. Too much white space, on the other hand, detracts from that readability. \begin{itemize} \item Indent using a four-space tab. Consistent tab spacing is necessary to maintain formatting. Note that this means when a tab is pressed, four physical spaces are inserted into the source instead. \item Put a blank line at the end of a public/protected/private block. \item Put a blank line at the end of every file. \item Put a space after every keyword (if, while, for, etc.). \item Put a space after every comma, unless the comma is at the end of the line. \item Do not put a space before the opening parenthesis of an argument list to a function. \item Declare pointers and references with the * or \& symbol next to the declarator, not the type; e.g., Object *object. Do not put multiple variables in the same declaration. \item Place a space on both sides of a binary operator. \item Do not use a space to separate a unary operator from its operand. \item Place open and close braces on their own line. No executable statements should appear on the line with the brace, but comments are allowed. Indent opening braces at the same level as the statement above and indent the closing brace at the same level as the corresponding opening brace. \item Indent all statements following an open brace by one tab. Developer Studio puts any specifier terminated with a colon at the same indentation level as the enclosing brace. Examples of such specifiers include case statements, access specifiers (public, private, protected), and goto labels. This is not acceptable and should be manually corrected so that all statements appearing within a block and delineated by braces are indented. \item Break a line into multiple lines when it becomes too long to read. Use at least two tabs to start the new line, so it does not look like the start of a block. \item Follow C++ style comments with one space. It is also preferable to consider any text that follows C++ style comments as a sentence and to begin this text with a capital letter. This helps to distinguish the line from a continuation of a previous line; i.e., \inlsh{// This is my comment.} \item As a general rule, don’t keep commented out source code in the final baselined product. Such code leads the reader to believe there was uncertainty in the code as it currently exists. \item Place the \# of a preprocessor directive at column one. An exception is the use of nested ifdefs where the bodies only contain other preprocessor directives. Add tabs to enhance readability: \begin{lstlisting}[style=C++Style] void foo() { for(int i = 0; i < 10; ++i) { #ifdef BAR do_something(); #endif for_loop_code(); } } \end{lstlisting} \item Use tabular white space if it enhances readability. \item Use only one return statement. Structure the code so that only one return statement is necessary. \end{itemize} \section{Naming Conventions} Keep variable and function names meaningful but concise. \begin{itemize} \item Begin variable names with lower-case letter. \item Begin function names and class names with upper-case letter. \item All function, class and variable names should be written in CamelCase, e.g. \inlsh{MyClass, DoFunction() or myVariableName}. \item All preprocessor definitions written in UPPER\_CASE with words separated by underscores, e.g. USE\_SPECIFIC\_FEATURE. \item All member variables prefixed with m\_. \item All constants prefixed with a k. \item All function parameters prefixed with a p. \item All enumerations prefixed with an e. \item Do not use leading underscores. \end{itemize} \section{Namespaces} The top-level namespace is "Nektar". All code should reside in this namespace or a sub-space of this. \begin{itemize} \item Namespaces correspond to code structure. \item Namespaces should be kept to a minimum to simplify the interface to their contents. \end{itemize} \section{Documentation} \begin{itemize} \item Briefs for classes, functions and types in header files using \inlsh{///} notation. \item Full documentation with implementation using \inlsh{/** ... *\/} notation. \item Use @ symbol for @class, @param, @returns, etc for ease of identification. \item Any separate documentation pages not directly associated with a portion of the code should be in a separate file in /docs/html/doxygen. \end{itemize}