@@ -26,23 +26,23 @@ Whitespaces:
26
26
- No whitespaces in blank lines
27
27
- Put argument lists on next line (and ident 2 spaces) if too long
28
28
- Put parameters on separate lines (and ident 2 spaces) if too long
29
- - No whitespaces around colon for inheritance,
29
+ - No whitespaces around colon for inheritance,
30
30
put inherited into separate lines in case of multiple inheritance
31
31
- The initializer list follows the constructor without a whitespace
32
32
around the colon. Break line after the colon if required and indent members.
33
33
- if(...), else, for(...), do, and while(...) are always in a separate line
34
- - Break expressions in if, for, while if necessary and align them
34
+ - Break expressions in if, for, while if necessary and align them
35
35
with the first character following the opening parenthesis
36
36
- Use {} instead of ; for the empty statement
37
- - Single line blocks without { } are allowed,
37
+ - Single line blocks without { } are allowed,
38
38
but put braces around multi-line blocks
39
- - Use blank lines to visually separate logically cohesive code blocks
39
+ - Use blank lines to visually separate logically cohesive code blocks
40
40
within a function
41
41
- Have a newline at the end of a file
42
42
43
43
Comments:
44
44
- Do not use /* */ except for file and function comment blocks
45
- - Each source and header file must start with a comment block
45
+ - Each source and header file must start with a comment block
46
46
stating the Module name and Author [will be changed when we roll out doxygen]
47
47
- Each function in the source file (not the header) is preceded
48
48
by a function comment header consisting of a comment block stating
@@ -75,9 +75,9 @@ Comments:
75
75
- Use #ifdef DEBUG to guard debug code
76
76
77
77
Naming:
78
- - Identifiers may use the characters [a-z0-9_] and should start with a
78
+ - Identifiers may use the characters [a-z0-9_] and should start with a
79
79
lower-case letter (parameters in constructors may start with _).
80
- - Use american spelling for identifiers.
80
+ - Use american spelling for identifiers.
81
81
- Separate basic words by _
82
82
- Avoid abbreviations (e.g. prefer symbol_table to of st).
83
83
- User defined type identifiers have to be terminated by 't'. Moreover,
@@ -122,7 +122,7 @@ Program Command Line Options
122
122
from the command line into the options
123
123
124
124
C++ features:
125
- - Do not use namespaces.
125
+ - Do not use namespaces, except for anonymous namespaces .
126
126
- Prefer use of 'typedef' insted of 'using'.
127
127
- Prefer use of 'class' instead of 'struct'.
128
128
- Write type modifiers before the type specifier.
@@ -136,7 +136,7 @@ C++ features:
136
136
- Avoid iterators, use ranged for instead
137
137
- Avoid allocation with new/delete, use unique_ptr
138
138
- Avoid pointers, use references
139
- - Avoid char *, use std::string
139
+ - Avoid char *, use std::string
140
140
- For numbers, use int, unsigned, long, unsigned long, double
141
141
- Use mp_integer, not BigInt
142
142
- Use the functions in util for conversions between numbers and strings
@@ -146,13 +146,13 @@ C++ features:
146
146
- Use instances of std::size_t for comparison with return values of .size() of
147
147
STL containers and algorithms, and use them as indices to arrays or vectors.
148
148
- Do not use default values in public functions
149
- - Use assertions to detect programming errors, e.g. whenever you make
149
+ - Use assertions to detect programming errors, e.g. whenever you make
150
150
assumptions on how your code is used
151
- - Use exceptions only when the execution of the program has to abort
151
+ - Use exceptions only when the execution of the program has to abort
152
152
because of erroneous user input
153
- - We allow to use 3rd-party libraries directly.
154
- No wrapper matching the coding rules is required.
155
- Allowed libraries are: STL.
153
+ - We allow to use 3rd-party libraries directly.
154
+ No wrapper matching the coding rules is required.
155
+ Allowed libraries are: STL.
156
156
- When throwing, omit the brackets, i.e. `throw "error"`.
157
157
- Error messages should start with a lower case letter.
158
158
- Use the auto keyword if and only if one of the following
@@ -165,12 +165,30 @@ Architecture-specific code:
165
165
- Don't include architecture-specific header files without #ifdef ...
166
166
167
167
Output:
168
- - Do not output to cout or cerr directly (except in temporary debug code,
168
+ - Do not output to cout or cerr directly (except in temporary debug code,
169
169
and then guard #include <iostream> by #ifdef DEBUG)
170
170
- Derive from messaget if the class produces output and use the streams provided
171
171
(status(), error(), debug(), etc)
172
172
- Use '\n' instead of std::endl
173
173
174
+ Unit tests:
175
+ - Unit tests are written using Catch: https://github.com/philsquared/Catch/
176
+ - For large classes:
177
+ - Create a separate file that contains the tests for each method of each
178
+ class
179
+ - The file should be named according to
180
+ `unit/class/path/class_name/function_name.cpp`
181
+ - For small classes:
182
+ - Create a separate file that contains the tests for all methods of each
183
+ class
184
+ - The file should be named according to unit/class/path/class_name.cpp
185
+ - Catch supports tagging, tests should be tagged with all the following tags:
186
+ - [core] should be used for all tests unless the test takes more than 1
187
+ second to run, then it should be tagged with [long]
188
+ - [folder_name] of the file being tested
189
+ - [class_name] of the class being tested
190
+ - [function_name] of the function being tested
191
+
174
192
You are allowed to break rules if you have a good reason to do so.
175
193
176
194
Pre-commit hook to run cpplint locally
0 commit comments