├── .clang-format ├── .gitignore ├── .travis.yml ├── Eclipse_O2_formatting.xml ├── LICENSE ├── README.md ├── coding_guidelines.html ├── comments_guidelines.html ├── naming_formatting.html ├── settings-o2-codestyle-clion.jar └── styleguide.css /.clang-format: -------------------------------------------------------------------------------- 1 | BasedOnStyle: Google 2 | AccessModifierOffset: -1 3 | AlignEscapedNewlinesLeft: true 4 | AlignTrailingComments: true 5 | AllowAllParametersOfDeclarationOnNextLine: false 6 | AllowShortFunctionsOnASingleLine: true 7 | AllowShortIfStatementsOnASingleLine: false 8 | AllowShortLoopsOnASingleLine: false 9 | #AlwaysBreakBeforeMultilineStrings: true 10 | AlwaysBreakTemplateDeclarations: true 11 | BinPackParameters: true 12 | BreakBeforeBinaryOperators: false 13 | BreakBeforeBraces: Linux 14 | BreakBeforeTernaryOperators: true 15 | BreakConstructorInitializersBeforeComma: false 16 | ColumnLimit: 0 17 | CommentPragmas: '^ IWYU pragma:' 18 | ConstructorInitializerAllOnOneLineOrOnePerLine: true 19 | ConstructorInitializerIndentWidth: 2 20 | ContinuationIndentWidth: 2 21 | Cpp11BracedListStyle: false 22 | DerivePointerBinding: false 23 | ExperimentalAutoDetectBinPacking: false 24 | IndentCaseLabels: true 25 | IndentFunctionDeclarationAfterType: true 26 | IndentWidth: 2 27 | # It is broken on windows. Breaks all #include "header.h" 28 | Language: Cpp 29 | MaxEmptyLinesToKeep: 1 30 | KeepEmptyLinesAtTheStartOfBlocks: true 31 | NamespaceIndentation: None 32 | ObjCSpaceAfterProperty: false 33 | ObjCSpaceBeforeProtocolList: false 34 | PenaltyBreakBeforeFirstCallParameter: 1 35 | PenaltyBreakComment: 300 36 | PenaltyBreakFirstLessLess: 120 37 | PenaltyBreakString: 1000 38 | PenaltyExcessCharacter: 1000000 39 | PenaltyReturnTypeOnItsOwnLine: 200 40 | SortIncludes: false 41 | SpaceBeforeAssignmentOperators: true 42 | SpaceBeforeParens: ControlStatements 43 | SpaceInEmptyParentheses: false 44 | SpacesBeforeTrailingComments: 1 45 | SpacesInAngles: false 46 | SpacesInContainerLiterals: true 47 | SpacesInCStyleCastParentheses: false 48 | SpacesInParentheses: false 49 | Standard: Cpp11 50 | TabWidth: 2 51 | UseTab: Never 52 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Created by .ignore support plugin (hsz.mobi) 2 | cmake-build-debug 3 | .idea -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: bash 2 | branches: 3 | only: 4 | - master 5 | script: 6 | echo "Nothing to do" 7 | after_success: | 8 | set -e 9 | curl -L https://github.com/github/hub/releases/download/v2.6.0/hub-linux-amd64-2.6.0.tgz | tar xz 10 | MESSAGE="Align Clang Format to upstream" 11 | REPOS="Common ReadoutCard AliceO2 InfoLogger QualityControl Monitoring Readout Configuration" 12 | ORG=${TRAVIS_REPO_SLUG%%/*} 13 | # We only build if the change involves .clang-format or .travis.yml. The latter 14 | # is to make sure that when we add new repositories we resync. 15 | if git diff --name-only $TRAVIS_COMMIT_RANGE | grep -e "\(.clang-format\|.travis.yml\)" ; then 16 | for REPO in $REPOS; do 17 | echo Processing $REPO 18 | git clone git://github.com/$ORG/$REPO 19 | cp .clang-format $REPO 20 | pushd $REPO 21 | git config user.email ${TRAVIS_SECURE_EMAIL} 22 | git config user.name ${TRAVIS_SECURE_USER} 23 | if git add .clang-format && git commit -m "${MESSAGE}"; then 24 | git push "https://${TRAVIS_SECURE_TOKEN_NAME}@github.com/$ORG/$REPO" HEAD:refs/heads/coding-guidelines-update -f > /dev/null 2>&1 25 | GITHUB_TOKEN=${TRAVIS_SECURE_TOKEN_NAME} ../hub-linux-amd64-2.6.0/bin/hub pull-request -h coding-guidelines-update -b master -m "Coding Guidelines update of $(date +%Y-%m-%d)" || true 26 | fi 27 | popd 28 | done 29 | fi 30 | branches: 31 | only: 32 | - master 33 | -------------------------------------------------------------------------------- /Eclipse_O2_formatting.xml: -------------------------------------------------------------------------------- 1 | 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 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU LESSER GENERAL PUBLIC LICENSE 2 | Version 3, 29 June 2007 3 | 4 | Copyright (C) 2007 Free Software Foundation, Inc. 5 | Everyone is permitted to copy and distribute verbatim copies 6 | of this license document, but changing it is not allowed. 7 | 8 | 9 | This version of the GNU Lesser General Public License incorporates 10 | the terms and conditions of version 3 of the GNU General Public 11 | License, supplemented by the additional permissions listed below. 12 | 13 | 0. Additional Definitions. 14 | 15 | As used herein, "this License" refers to version 3 of the GNU Lesser 16 | General Public License, and the "GNU GPL" refers to version 3 of the GNU 17 | General Public License. 18 | 19 | "The Library" refers to a covered work governed by this License, 20 | other than an Application or a Combined Work as defined below. 21 | 22 | An "Application" is any work that makes use of an interface provided 23 | by the Library, but which is not otherwise based on the Library. 24 | Defining a subclass of a class defined by the Library is deemed a mode 25 | of using an interface provided by the Library. 26 | 27 | A "Combined Work" is a work produced by combining or linking an 28 | Application with the Library. The particular version of the Library 29 | with which the Combined Work was made is also called the "Linked 30 | Version". 31 | 32 | The "Minimal Corresponding Source" for a Combined Work means the 33 | Corresponding Source for the Combined Work, excluding any source code 34 | for portions of the Combined Work that, considered in isolation, are 35 | based on the Application, and not on the Linked Version. 36 | 37 | The "Corresponding Application Code" for a Combined Work means the 38 | object code and/or source code for the Application, including any data 39 | and utility programs needed for reproducing the Combined Work from the 40 | Application, but excluding the System Libraries of the Combined Work. 41 | 42 | 1. Exception to Section 3 of the GNU GPL. 43 | 44 | You may convey a covered work under sections 3 and 4 of this License 45 | without being bound by section 3 of the GNU GPL. 46 | 47 | 2. Conveying Modified Versions. 48 | 49 | If you modify a copy of the Library, and, in your modifications, a 50 | facility refers to a function or data to be supplied by an Application 51 | that uses the facility (other than as an argument passed when the 52 | facility is invoked), then you may convey a copy of the modified 53 | version: 54 | 55 | a) under this License, provided that you make a good faith effort to 56 | ensure that, in the event an Application does not supply the 57 | function or data, the facility still operates, and performs 58 | whatever part of its purpose remains meaningful, or 59 | 60 | b) under the GNU GPL, with none of the additional permissions of 61 | this License applicable to that copy. 62 | 63 | 3. Object Code Incorporating Material from Library Header Files. 64 | 65 | The object code form of an Application may incorporate material from 66 | a header file that is part of the Library. You may convey such object 67 | code under terms of your choice, provided that, if the incorporated 68 | material is not limited to numerical parameters, data structure 69 | layouts and accessors, or small macros, inline functions and templates 70 | (ten or fewer lines in length), you do both of the following: 71 | 72 | a) Give prominent notice with each copy of the object code that the 73 | Library is used in it and that the Library and its use are 74 | covered by this License. 75 | 76 | b) Accompany the object code with a copy of the GNU GPL and this license 77 | document. 78 | 79 | 4. Combined Works. 80 | 81 | You may convey a Combined Work under terms of your choice that, 82 | taken together, effectively do not restrict modification of the 83 | portions of the Library contained in the Combined Work and reverse 84 | engineering for debugging such modifications, if you also do each of 85 | the following: 86 | 87 | a) Give prominent notice with each copy of the Combined Work that 88 | the Library is used in it and that the Library and its use are 89 | covered by this License. 90 | 91 | b) Accompany the Combined Work with a copy of the GNU GPL and this license 92 | document. 93 | 94 | c) For a Combined Work that displays copyright notices during 95 | execution, include the copyright notice for the Library among 96 | these notices, as well as a reference directing the user to the 97 | copies of the GNU GPL and this license document. 98 | 99 | d) Do one of the following: 100 | 101 | 0) Convey the Minimal Corresponding Source under the terms of this 102 | License, and the Corresponding Application Code in a form 103 | suitable for, and under terms that permit, the user to 104 | recombine or relink the Application with a modified version of 105 | the Linked Version to produce a modified Combined Work, in the 106 | manner specified by section 6 of the GNU GPL for conveying 107 | Corresponding Source. 108 | 109 | 1) Use a suitable shared library mechanism for linking with the 110 | Library. A suitable mechanism is one that (a) uses at run time 111 | a copy of the Library already present on the user's computer 112 | system, and (b) will operate properly with a modified version 113 | of the Library that is interface-compatible with the Linked 114 | Version. 115 | 116 | e) Provide Installation Information, but only if you would otherwise 117 | be required to provide such information under section 6 of the 118 | GNU GPL, and only to the extent that such information is 119 | necessary to install and execute a modified version of the 120 | Combined Work produced by recombining or relinking the 121 | Application with a modified version of the Linked Version. (If 122 | you use option 4d0, the Installation Information must accompany 123 | the Minimal Corresponding Source and Corresponding Application 124 | Code. If you use option 4d1, you must provide the Installation 125 | Information in the manner specified by section 6 of the GNU GPL 126 | for conveying Corresponding Source.) 127 | 128 | 5. Combined Libraries. 129 | 130 | You may place library facilities that are a work based on the 131 | Library side by side in a single library together with other library 132 | facilities that are not Applications and are not covered by this 133 | License, and convey such a combined library under terms of your 134 | choice, if you do both of the following: 135 | 136 | a) Accompany the combined library with a copy of the same work based 137 | on the Library, uncombined with any other library facilities, 138 | conveyed under the terms of this License. 139 | 140 | b) Give prominent notice with the combined library that part of it 141 | is a work based on the Library, and explaining where to find the 142 | accompanying uncombined form of the same work. 143 | 144 | 6. Revised Versions of the GNU Lesser General Public License. 145 | 146 | The Free Software Foundation may publish revised and/or new versions 147 | of the GNU Lesser General Public License from time to time. Such new 148 | versions will be similar in spirit to the present version, but may 149 | differ in detail to address new problems or concerns. 150 | 151 | Each version is given a distinguishing version number. If the 152 | Library as you received it specifies that a certain numbered version 153 | of the GNU Lesser General Public License "or any later version" 154 | applies to it, you have the option of following the terms and 155 | conditions either of that published version or of any later version 156 | published by the Free Software Foundation. If the Library as you 157 | received it does not specify a version number of the GNU Lesser 158 | General Public License, you may choose any version of the GNU Lesser 159 | General Public License ever published by the Free Software Foundation. 160 | 161 | If the Library as you received it specifies that a proxy can decide 162 | whether future versions of the GNU Lesser General Public License shall 163 | apply, that proxy's public statement of acceptance of any version is 164 | permanent authorization for you to choose that version for the 165 | Library. 166 | 167 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![JIRA](https://img.shields.io/badge/JIRA-Report%20issue-blue.svg)](https://alice.its.cern.ch/jira/secure/CreateIssue.jspa?pid=11201&issuetype=1) 2 | 3 | # ALICE O2 Coding Guidelines 4 | Coding guidelines for the ALICE O2 project. 5 | 6 | ### Documents 7 | 8 | * [Coding guidelines](https://rawgit.com/AliceO2Group/CodingGuidelines/master/coding_guidelines.html) 9 | * [Naming and formatting conventions](https://rawgit.com/AliceO2Group/CodingGuidelines/master/naming_formatting.html) 10 | * [Comments guidelines](https://rawgit.com/AliceO2Group/CodingGuidelines/master/comments_guidelines.html) 11 | 12 | ### Formatting tool 13 | The ALICE O2 projects use `clang-format` to push for a common code formatting. The rules are defined in 14 | the `clang-format` configuration file in this repository (which is propagated to other AliceO2Group repositories). With an adiabatic 15 | approach, all changes have to follow the formatting rules. A script, described below, can be 16 | used to integrate the formatting into `git` and suggest formatting only for 17 | changed lines. 18 | 19 | #### Install `clang-format` and git integration 20 | 21 | Note : The installation of clang using aliBuild is not necessary on Mac. 22 | 23 | 1. Build clang (to be done once) 24 | ```bash 25 | aliBuild build --defaults o2 Clang 26 | ``` 27 | 2. Load clang and clang-format 28 | ```bash 29 | alienv enter Clang/latest 30 | ``` 31 | 3. Install git-clang-format 32 | ```bash 33 | cd $HOME 34 | mkdir -p bin 35 | cd bin 36 | wget https://raw.githubusercontent.com/llvm/llvm-project/main/clang/tools/clang-format/git-clang-format 37 | chmod u+x git-clang-format 38 | ``` 39 | 40 | #### Check commits' formatting 41 | `git clang-format` invokes `clang-format` on the changes in current files 42 | or a specific commit. E.g. for the last commit 43 | ``` 44 | git clang-format HEAD~1 45 | ``` 46 | 47 | Or for all commits done with respect to the remote branch state 48 | ``` 49 | git clang-format origin/dev 50 | ``` 51 | 52 | #### Check files' formatting 53 | 54 | The commands below rely on the [.clang-format](.clang-format) file located in one of the parent 55 | directories of the source files. 56 | 57 | Please note that for technical reasons, there are slight differences between `clang-format` and `git-clang-format` (see above). All pull requests are checked with `git-clang-format` as described in the previous bullet. Thus make sure that before pushing code, correct the formatting with `git-clang-format`. The instructions for `clang-format` are left here only for reference. 58 | 59 | Show correctly formatted version of a file : 60 | ``` 61 | clang-format -style=file SOURCEFILE 62 | ``` 63 | 64 | Directly apply the style to a file : 65 | ``` 66 | clang-format -style=file -i SOURCEFILE 67 | ``` 68 | 69 | Apply the style to all the source and header files in a directory (recursive) : 70 | 71 | ``` 72 | find . -iname "*.h" -o -iname "*.cpp" | xargs clang-format -style=file -i 73 | ``` 74 | 75 | Display what needs to be fixed in a file : 76 | ``` 77 | clang-format -style=file | diff - 78 | ``` 79 | 80 | #### Using an IDE 81 | A number of config files are available [here](https://github.com/AliceO2Group/CodingGuidelines) for various IDEs. 82 | 83 | ### O2 code checker 84 | All the AliceO2 pull requests are subject to be tested with [O2 CodeChecker](https://github.com/AliceO2Group/O2CodeChecker#readme) during `build/O2/fullCI` check. It is a bit stricter tool than `clang-format`. Contributors are encouraged to run the codecheck locally before creating a pull request in order to save checking time and CPU resources of the testing facilities. Try to run it in the root directory of your installation: 85 | ``` 86 | aliBuild build o2checkcode --defaults o2 87 | ``` 88 | In case of success you'll be informed of it: 89 | ``` 90 | ==> Build of o2checkcode successfully completed on `your-pc-name'. 91 | ``` 92 | Otherwise an ERROR messages will appear: 93 | ``` 94 | ==> Building o2checkcode@1.0 95 | ==> o2checkcode is being built (use --debug for full output): failed 96 | ERROR: Error while executing /your/path/sw/SPECS/ubuntu2004_x86-64/o2checkcode/1.0-local1/build.sh on `your-pc-name'. 97 | ERROR: Log can be found in /your/path/sw/BUILD/o2checkcode-latest/log 98 | ``` 99 | You'll find details of the problem at the __end__ of logfile: `/your/path/sw/BUILD/o2checkcode-latest/log`. For example: 100 | ``` 101 | ========== List of errors found ========== 102 | /sw/SOURCES/O2/7084-slc8_x86-64/0/Detectors/CPV/calib/include/CPVCalibration/PedestalCalibrator.h:78:3: error: use '= default' to define a trivial destructor [modernize-use-equals-default] 103 | ``` 104 | There could be other errors before `========== List of errors found ==========` but they are not relevant. Important ones go after the mentioned line. 105 | 106 | The use of o2checkcode is tested at CC8/CS8 and Ubuntu 20.04.3 LTS. People reported failure of successful running o2checkcode on other systems. Alternative ways to run code checker are following: 107 | 1. Try above mentioned way in a Docker container used for CI tests, namely `alisw/slc8-gpu-builder`; 108 | 2. Run O2CodeChecker manually in build directory of O2 project. The instructions can be found [here](https://github.com/AliceO2Group/O2CodeChecker#usage). 109 | 110 | ### Configuration files for editors 111 | 112 | #### CLion 113 | 1. [Download](https://github.com/AliceO2Group/CodingGuidelines/raw/master/settings-o2-codestyle-clion.jar), 114 | 2. Go to File -> Import Settings. 115 | 116 | ## FAQ 117 | * __Q__ I strongly disagree with rule X ! 118 | * __A__ Feel free to contact the WP3 (alice-o2-wp3@cern.ch) to share your concern(s). Rules have already been amended, abandoned or added based on the users feedback. However, please comply with the rules until a change is agreed by CWG11. 119 | 120 | -------------------------------------------------------------------------------- /comments_guidelines.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | ALICE O² C++ Comments Guidelines 4 | 5 | 6 | 7 | 143 | 144 | 145 |

ALICE O² C++ Comments Guidelines

146 | 147 |
148 | Vasco Barroso
149 | Alina GrigoraȘ
150 | Ivana Hřivnáčová
151 | Matthias Kretz
152 | Adriana Telesca
153 | Barthélémy von Haller
154 |
155 | 156 |

157 | This document is based on the work of
158 | B. Weinberger, C. Silverstein,
159 | G. Eitzmann, M. Mentovai
160 | and T.Landray
161 | at http://google-styleguide.googlecode.com,
162 | C++ Google Style guide, Revision 3.274
163 | under the CC-By 3.0 License 164 |

165 | 166 | 167 |
168 |

169 | Each style point has a summary for which additional information is available 170 | by toggling the accompanying arrow button that looks this way: 171 | ▶. 172 | You may toggle all summaries with the big arrow button: 173 |

174 |
175 | ▶ 176 | Toggle all summaries 177 |
178 |
179 |
180 |
Table of Contents
181 | 182 | 183 | 184 | 186 | 187 | 188 | 189 | 191 | 192 |
General
185 | General Guidelines Doxygen Mandatory Documentation Comments Style Punctuation, Spelling and Grammar Special Characters
How to Document Your Code
190 | Files Classes Functions Class Data Members Namespaces Enumerations Macros Other
193 |
194 |
195 |

Important Note

196 |
197 |

Displaying Hidden Details in this Guide

198 | 199 | link 200 | ▶ 201 |
202 | This style guide contains many details that are initially 203 | hidden from view. They are marked by the triangle icon, which you 204 | see here on your left. Click it now. 205 | You should see "Hooray" appear below. 206 |
207 |
214 |
215 |
216 | 217 | 218 |
219 |

General

220 |
221 |

General Guidelines

222 | 223 | link 224 | ▶ 225 |

226 | Though a pain to write, comments are absolutely vital to keeping our 227 | code readable. The following rules describe what you should 228 | comment and where. But remember: while comments are very 229 | important, the best code is self-documenting. Giving sensible 230 | names to types and variables is much better than using obscure 231 | names that you must then explain through comments. 232 |

233 |

234 | When writing your comments, write for your audience: the next 235 | contributor 236 | who will need to understand your code. Be generous — the next 237 | one may be you! 238 |

239 |
240 | 241 | 242 |
243 |

Doxygen

244 | 245 | link 246 | ▶ 247 |
248 | Following an evaluation of different code documentation tools, Doxygen has been selected. 249 | Doxygen [1] allows different comments style. We recommend to use a block of C++ comment lines, where each line starts with an additional slash. 250 | 
/// ... text ...
251 | /// ... text ...
252 |
253 |
279 |
280 |
281 |

Mandatory Documentation

282 | 283 | link 284 | ▶ 285 |
286 | There are a certain number of items that must be documented. 287 | They are: 288 |
    289 |
  • Files.
    • 290 |
  • Classes.
    • 291 |
  • Functions.
    • 292 |
  • Data members.
    • 293 |
  • Namespaces.
    • 294 |
  • Enumerations and enumerators.
    • 295 |
  • Macros.
    • 296 |
297 | The following sections show how to document each one of these items. 298 | First of all, we will go through general guidelines that will help you to document your code. 299 |
300 |
302 |
303 | 304 |
305 |

Comments Style

306 | 307 | link 308 | ▶ 309 |
310 | Use the /// syntax for the comments going in the 311 | Web documentation, the // syntax for explicative 312 | comments in the code and the /* */ syntax only for 313 | the comments within one line. 314 |
315 |
332 |
333 | 334 |
335 |

Punctuation, Spelling and Grammar

336 | 337 | link 338 | ▶ 339 |
340 | Pay attention to punctuation, spelling, and grammar; it is 341 | easier to read well-written comments than badly written ones. 342 |
343 |
359 |
360 | 361 |
362 |

Special Characters

363 | 364 | link 365 | ▶ 366 |
367 | While non-ASCII characters are not allowed in names used in the code, 368 | use of Unicode e.g. for proper math formulas in comments is encouraged. 369 |
370 |
395 |
396 |
397 | 398 |
399 |

How to Document Your Code

400 | 401 | 402 |
403 |

Files

404 | 405 | link 406 | ▶ 407 |
408 | Start each file with copyright boilerplate, 409 | followed by a description of its contents. 410 |
411 |
460 |
461 | 462 |
463 |

Classes

464 | 465 | link 466 | ▶ 467 |
468 | Every class definition should have an accompanying comment that 469 | describes what it is for and how it should be used. 470 | The comment should be placed just before class keyword. 471 |
472 |
487 |
488 | 489 |
490 |

Functions

491 | 492 | link 493 | ▶ 494 |
495 | Declaration comments describe use of the function; comments at 496 | the definition of a function describe operation. 497 |
498 |
557 |
558 | 559 |
560 |

Class Data Members

561 | 562 | link 563 | ▶ 564 |
565 | Each class data member (also called an instance variable or 566 | member variable) should have a comment describing what it is 567 | used for. If the variable can take sentinel values with 568 | special meanings, such as a null pointer or -1, document this. 569 | 570 |
571 |
610 |
611 |
612 |

Namespaces

613 | 614 | link 615 | ▶ 616 |
617 | Every namespace definition should have an accompanying comment that 618 | describes what it is for. The comment should be placed just before 619 | namespace keyword. 620 |
621 |
636 |
637 | 638 |
639 |

Enumerations

640 | 641 | link 642 | ▶ 643 |
644 | Always provide a description of the enumerations and their enumerators values. 645 |
646 |
659 |
660 | 661 |
662 |

Macros

663 | 664 | link 665 | ▶ 666 |
667 | Always provide an explanation of what the macro is used for and how. 668 |
669 |
671 |
672 |
673 |

Other

674 | 675 | link 676 | ▶ 677 |
678 | Complex code blocks/lines, To do comments, etc. 679 |
680 | 681 |
737 |
738 |
739 | 740 | 741 |

References

742 |

743 | [1] Doxygen [http://www.doxygen.org] 744 |

745 | 746 | 747 | 748 | 749 | -------------------------------------------------------------------------------- /naming_formatting.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | ALICE O² C++ Naming & Formatting Rules 4 | 5 | 6 | 7 | 134 | 135 | 136 |

ALICE O² C++ Naming & Formatting Rules

137 | 138 |
139 | Vasco Barroso
140 | Alina GrigoraȘ
141 | Ivana Hřivnáčová
142 | Matthias Kretz
143 | Adriana Telesca
144 | Barthélémy von Haller
145 |
146 | 147 |

148 | This document is based on the work of
149 | B. Weinberger, C. Silverstein,
150 | G. Eitzmann, M. Mentovai
151 | and T.Landray
152 | at http://google-styleguide.googlecode.com,
153 | C++ Google Style guide, Revision 3.245
154 | under the CC-By 3.0 License 155 |

156 | 157 |
158 |

159 | Each style point has a summary for which additional information is available 160 | by toggling the accompanying arrow button that looks this way: 161 | ▶. 162 | You may toggle all summaries with the big arrow button: 163 |

164 |
165 | ▶ 166 | Toggle all summaries 167 |
168 |
169 |
170 |
Table of Contents
171 | 172 | 173 | 174 | 188 | 189 | 190 | 191 | 193 | 194 | 195 | 196 | 198 | 199 |
Naming
175 | General Naming Rules 176 | Code File Names 177 | Executable Names 178 | Library Names 179 | Type Names 180 | Interface Names 181 | Variable Names 182 | Function Names 183 | Namespace Names 184 | Enumerator Names 185 | Macro Names 186 |
187 |
Formatting
192 | Line Length One Statement Per Line Spaces vs. Tabs Function Declarations and Definitions Pointer and Reference Expressions Boolean Expressions Variable and Array Initialization Preprocessor Directives Classes Constructor Initializer Lists Namespaces Braces Horizontal Whitespace Vertical Whitespace Where to put const
Exceptions to the Rules
197 | Existing Non-conformant Code
200 |
201 |
202 |

Background

203 |

204 | The goal of this guide is to provide a number of rules that keep the code base manageable by enforcing 205 | consistency. 206 | 207 | It is very important that any programmer 208 | can look at another programmer's code and understand it quickly. 209 | Maintaining a uniform style and following conventions means that "pattern-matching" can be 210 | more easily used to identify different symbols and invariants. 211 |

212 |

213 | Creating common, required 214 | idioms and patterns makes code much easier to understand. In some 215 | cases there might be good arguments for changing certain style 216 | rules. Nonetheless, for reasons of consistency the rules are left unchanged. 217 |

218 | 219 |

220 | Note that this guide is not a C++ tutorial: we assume that the 221 | reader is familiar with the language. 222 | 223 |

224 | 225 |
226 | 227 | 228 |
229 |

Naming

230 |

231 | The most important consistency rules are those that govern 232 | naming. The style of a name immediately informs us what sort of 233 | thing the named entity is: a type, a variable, a function, a macro, etc., without requiring us to search for the 234 | declaration of that entity. The pattern-matching engine in our 235 | brains relies a great deal on these naming rules. 236 |

237 |

238 | Naming rules are pretty arbitrary, but we feel that consistency is more important than individual preferences in this area, so regardless of whether you find them sensible or not, the rules are the rules. 239 |

240 | 241 |
242 |

General Naming Rules

243 | 244 | link 245 | ▶ 246 |
247 | Names should be meaningful; abbreviations should be avoided. 248 | They follow camel case convention. Types and variables should be nouns, 249 | while functions should be "command" verbs.
250 |
345 |
346 | 347 |
348 |

Code File Names

349 | 350 | link 351 | ▶ 352 |

353 |
354 | C++ code file names are derived from the class (or the namespace) 355 | names.
356 | Program file names and utility file names, which do not define a class 357 | or a namespace, start with a lower case letter.
358 |
359 |
388 |
389 | 390 |
391 |

392 | Executable Names 393 |

394 | 395 | link 396 | 397 | ▶ 399 |
400 | Executable names should be in lowercase, prefixed with o2, and hyphenated : o2-tpc-reco-workflow 401 |
402 |
403 | 415 |
416 |
417 | 418 |
419 |

420 | Library Names 421 |

422 | 423 | link 424 | 425 | ▶ 427 |
428 | Library names should follow camel case convention (with the exception of the subsystem names) and be prefixed with 429 | O2. 430 |
431 |
432 | 442 |
443 |
444 | 445 |
446 |

Type Names

447 | 448 | link 449 | ▶ 450 |
451 | Type names follow camel case convention and start with an upper case letter: 452 | MyClass, MyEnum. 453 |
454 |
473 |
474 | 475 |
476 |

Interface Names

477 | 478 | link 479 | ▶ 480 |
481 | The "Interface" suffix can optionally be used only if a class matches the Pure Interface requirements. 482 |
483 |
488 |
489 | 490 |
491 |

Variable Names

492 | 493 | link 494 | ▶ 495 |
496 | Variable names follow camel case convention and start with 497 | a lower case letter: myLocalVariable. 498 |
    499 |
  • Class member variables are prefixed with m.
    • 500 |
  • Static class member variables are prefixed with s.
    • 501 |
  • No m prefix for struct members.
    • 502 |
  • Global variables are prefixed with g.
    • 503 |
  • 504 | constexpr variables are capitalized.
    • 505 |
  • No additional prefix for const.
    • 506 |
507 |
508 |
574 |
575 | 576 |
577 |

Function Names

578 | 579 | link 580 | ▶ 581 |
582 | Regular functions follow camel case convention and start with a lower case 583 | letter: myFunction(). 584 | 585 |
    586 |
  • Accessors and mutators match the name of the variable and are 587 | prefixed with get and set: 588 | getMyMemberVariable(), setMyMemberVariable().
    • 589 |
  • Functions (including accessors) returning a boolean value should be prefixed with 590 | is or has.
    • 591 |
592 |
593 |
648 |
649 | 650 |
651 |

Namespace Names

652 | 653 | link 654 | ▶ 655 |
656 | Namespace names follow underscore convention and start with a lower case 657 | letter: my_namespace. 658 |
659 |
669 |
670 | 671 |
672 |

Enumerator Names

673 | 674 | link 675 | ▶ 676 |
677 | Enumerations and enumerators (the type and the values) follow camel case 678 | convention and start with an upper case letter: 679 | MyEnumType, MyEnumValue. 680 |
    681 |
  • Enumerators in unscoped enumerations should have a common 682 | prefix/postfix derived from the enumerations name.
    • 683 |
  • Enum classes are already scoped and therefore the enumerators do not 684 | need a prefix/postfix.
    • 685 |
686 |
687 |
748 |
749 | 750 |
751 |

Macro Names

752 | 753 | link 754 | ▶ 755 |
756 | All uppercase letters and underscores, prefixed with the sub/project name, i.e. MY_PROJECT_PKG1_MY_MACRO. 757 |
758 |
775 |
776 |
777 | 778 |
779 |

Formatting

780 |

781 | Coding style and formatting are pretty arbitrary. However, a good project 782 | is much easier to follow if everyone uses the same style. Individuals 783 | may not agree with every aspect of the formatting rules, and some of 784 | the rules may be hard to get used to. Even so, it is important that all 785 | 786 | project contributors 787 | follow the style rules so that 788 | 789 | they 790 | can all read and understand everyone's code easily. 791 |

792 | 793 |
794 |

Line Length

795 | 796 | link 797 | ▶ 798 |
799 | Each line of text in your code should be at most 120 characters 800 | long. 801 |
802 |
809 |
810 | 811 |
812 |

One Statement Per Line

813 | 814 | link 815 | ▶ 816 |
817 | Prefer one statement per line because it improves code readability. 818 |
819 |
830 |
831 | 832 |
833 |

Spaces vs. Tabs

834 | 835 | link 836 | ▶ 837 |
838 | Indent with 2 spaces. Use only spaces, no tabs. 839 |
840 |
847 |
848 | 849 |
850 |

Function Declarations and Definitions

851 | 852 | link 853 | ▶ 854 |
855 | A function declaration is on one line if possible. Otherwise the parameters that do not 856 | fit are on the next line(s). 857 |
858 |
877 |
878 | 879 |
880 |

Pointer and Reference Expressions

881 | 882 | link 883 | ▶ 884 |
885 | No spaces around period or arrow. Pointer operators are either followed 886 | or preceded with a space. 887 |
888 |
910 |
911 | 912 |
913 |

Boolean Expressions

914 | 915 | link 916 | ▶ 917 |
918 | In the case of a boolean expression that is longer than the standard line length, lines should be broken up in a consistent way. All operators should be either at the beginning or at the end of the line. 919 |
920 |
931 |
932 | 933 | 934 |
935 |

Variable and Array Initialization

936 | 937 | link 938 | ▶ 939 |
940 | Prefer initialization with braces except for single-argument assignment. 941 |
942 |
970 |
971 | 972 |
973 |

Preprocessor Directives

974 | 975 | link 976 | ▶ 977 |
978 | The hash mark that starts a preprocessor directive is 979 | always at the beginning of the line. 980 |
981 |
1005 |
1006 | 1007 |
1008 |

Classes

1009 | 1010 | link 1011 | ▶ 1012 |
1013 | Access specifiers in a class or a struct are indented by 1 space. 1014 | The sections they delimit are themselves indented by 1 more space for a total of 2 spaces. 1015 |
1016 |
1080 |
1081 | 1082 |
1083 |

Constructor Initializer Lists

1084 | 1085 | link 1086 | ▶ 1087 |
1088 | Constructor initializer lists should be with subsequent lines indented 1089 | properly. Alternatively, they can be all in a single line. 1090 |
1091 |
1109 |
1110 | 1111 |
1112 |

Namespaces

1113 | 1114 | link 1115 | ▶ 1116 |
1117 | The contents of namespaces are not indented. 1118 |
1119 |
1156 |
1157 | 1158 |
1159 |

Braces

1160 | 1161 | link 1162 | ▶ 1163 |
1164 | As a base rule, the left curly brace is on the same line as the start of 1165 | the statement. In control constructs, the braces must be used even if their body 1166 | consists of only one statement. 1167 |
1168 |
1206 |
1207 | 1208 |
1209 |

Horizontal Whitespace

1210 | 1211 | link 1212 | ▶ 1213 |
Recommended guidelines: 1214 |
    1215 |
  • One space should be used after each keyword.
    • 1216 |
  • No extra spaces inside parenthesis and angle brackets (templates).
    • 1217 |
  • Spaces should be used around binary operators.
    • 1218 |
  • No space between a unary operator and its operand.
    • 1219 |
  • Never put trailing whitespace at the end of a line.
    • 1220 |
1221 |
1222 |
1257 |
1258 | 1259 | 1260 |
1261 |

Vertical Whitespace

1262 | 1263 | link 1264 | ▶ 1265 |
1266 | Use only one empty line to separate code. 1267 |
1268 |
1269 | 1270 |
1271 |

Where to put const

1272 | 1273 | link 1274 | ▶ 1275 |
1276 | Put const before the type when defining a const variable. 1277 |
1278 |
1292 |
1293 |
1294 | 1295 | 1296 | 1297 |
1298 |

Exceptions to the Rules

1299 |

1300 | The coding conventions described above have to be followed. However, 1301 | like all good rules, these sometimes have exceptions. 1302 |

1303 | 1304 |
1305 |

Existing Non-conformant Code

1306 | 1307 | link 1308 | ▶ 1309 |
1310 | It is permissible to deviate from the rules when dealing with code that does not 1311 | conform to this style guide. For example, in naming something that is analogous to an existing C or C++ entity then the existing naming convention 1312 | scheme can be followed. 1313 |
1314 |
1333 |
1334 |
1335 | 1336 |

Parting Words

1337 |

1338 | Use common sense and BE CONSISTENT. 1339 |

1340 |

1341 | When editing code, take a few minutes to look at the 1342 | code and determine its style. 1343 |

1344 |

1345 | The point about having style guidelines is to have a common 1346 | vocabulary of coding so people can concentrate on what the programmer 1347 | is saying, rather than on how he/she is saying it. Global style rules are presented here so people know the vocabulary. However, 1348 | local style is also important. If the code added to a file 1349 | looks drastically different from the existing code around it, 1350 | the discontinuity throws readers out of their rhythm when they 1351 | go to read it. Try to avoid this. 1352 |

1353 | 1354 |

1355 | OK, enough writing about writing code; the code itself is much 1356 | more interesting. Have fun! 1357 |

1358 | 1359 | 1360 |

References

1361 |

1362 | [1] Herb Sutter on software, hardware, and concurrency blog [http://herbsutter.com/2013/05/09/gotw-1-solution] 1363 |

1364 | 1365 | 1366 | 1367 | 1368 | -------------------------------------------------------------------------------- /settings-o2-codestyle-clion.jar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AliceO2Group/CodingGuidelines/5c44b8bae3236da4dc8106dc2385825ddb112c4c/settings-o2-codestyle-clion.jar -------------------------------------------------------------------------------- /styleguide.css: -------------------------------------------------------------------------------- 1 | body { 2 | background-color: #fff; 3 | color: #0e212e; 4 | font-family: sans-serif; 5 | font-size: 10pt; 6 | margin-right: 100px; 7 | margin-left: 100px; 8 | } 9 | 10 | a:link { 11 | color: #1f2669; 12 | } 13 | 14 | a:visited { 15 | color: #2b6790; 16 | } 17 | 18 | a:hover { 19 | color: #691f4b; 20 | } 21 | 22 | h1, h2, h3, h4, h5, h6, .toc_title { 23 | font-family: sans-serif; 24 | color: #1f4b69; 25 | margin-top: 2em; 26 | margin-bottom: 1em; 27 | } 28 | 29 | h1 { 30 | text-align: center; 31 | font-size: 18pt; 32 | } 33 | 34 | h2, .toc_title { 35 | font-weight: bold; 36 | font-size: 12pt; 37 | margin-left: -40px; 38 | } 39 | 40 | h3, h4, h5, h6 { 41 | font-size: 10pt; 42 | margin-left: -20px; 43 | } 44 | 45 | // clear floating boxes (C++11 box) on new stylepoints / categories 46 | h1, h2, h3 { 47 | clear: right; 48 | } 49 | 50 | .toc_category, .toc_stylepoint { 51 | font-family: sans-serif; 52 | font-size: 10pt; 53 | padding-top: .3em; 54 | padding-bottom: .3em; 55 | } 56 | 57 | table { 58 | border-collapse: collapse; 59 | } 60 | 61 | td, th { 62 | border: 1px solid #ccc; 63 | padding: 2px 12px; 64 | font-size: 10pt; 65 | } 66 | 67 | .toc td, .toc th { 68 | border-width: 1px 5px; 69 | } 70 | 71 | .todo_section { 72 | font-size: 150%; 73 | font-weight: bold; 74 | } 75 | 76 | code, samp, var { 77 | color: #2a6790; 78 | } 79 | 80 | div.cpp11box { 81 | float: right; 82 | clear: right; 83 | width: 50%; 84 | margin-right: -80px; 85 | margin-left: 1em; 86 | margin-top: 1ex; 87 | margin-bottom: 1ex; 88 | display: block; 89 | border-color: #1f4b69; 90 | border-style: solid; 91 | border-width: 1px; 92 | border-radius: 5px; 93 | -webkit-border-radius: 5px; 94 | -moz-border-radius: 5px; 95 | background-color: #dff3ff; 96 | padding: 0; 97 | } 98 | div.cpp11Header { 99 | background-color: #1f4b69; 100 | color: #dff3ff; 101 | text-align: right; 102 | margin: 0; 103 | padding-left: 0.5em; 104 | padding-right: 1.0em; 105 | padding-top: 2px; 106 | padding-bottom: 0; 107 | border-radius: 4px 4px 0 0; 108 | -webkit-border-radius: 4px 4px 0 0; 109 | -moz-border-radius: 4px 4px 0 0; 110 | } 111 | div.cpp11 { 112 | margin-left: 0.5em; 113 | margin-right: 0.5em; 114 | margin-top: 0.5ex; 115 | margin-bottom: 0.5em; 116 | padding: 0; 117 | } 118 | 119 | pre { 120 | white-space: pre-wrap; 121 | font-size: 10pt; 122 | display: block; 123 | color: #2a6790; 124 | background-color: #f8fff8; 125 | border-color: #f0fff0; 126 | border-style: solid; 127 | border-top-width: 1px; 128 | border-bottom-width: 1px; 129 | border-right-width: 1px; 130 | border-left-width: 5px; 131 | padding-left: 12px; 132 | padding-right: 12px; 133 | padding-top: 4px; 134 | padding-bottom: 4px; 135 | } 136 | 137 | pre.badcode { 138 | color: #c00; 139 | background-color: #fff8f8; 140 | border-color: #fff0f0; 141 | } 142 | 143 | .showhide_extrabutton, 144 | .showhide_button { 145 | float: left; 146 | cursor: pointer; 147 | border-width: 1px; 148 | border-style: solid; 149 | border-color: #ddd #aaa #aaa #ddd; 150 | padding: 0 3px 1px; 151 | margin: 0 4px 8px 0; 152 | border-radius: 3px; 153 | -webkit-border-radius: 3px; 154 | -moz-border-radius: 3px; 155 | } 156 | 157 | .link_button { 158 | float: left; 159 | display: none; 160 | background-color: #f8f8ff; 161 | border-color: #f0f0ff; 162 | border-style: solid; 163 | border-width: 1px; 164 | font-size: 75%; 165 | margin-top: 0; 166 | margin-left: -50px; 167 | padding: 4px; 168 | border-radius: 3px; 169 | -webkit-border-radius: 3px; 170 | -moz-border-radius: 3px; 171 | } 172 | 173 | .cpp11_marker { 174 | float: left; 175 | background-color: #1f4b69; 176 | border-color: #1f4b69; 177 | border-style: solid; 178 | border-width: 1px; 179 | color: #dff3ff; 180 | font-size: 75%; 181 | font-weight: bold; 182 | margin-top: 3ex; 183 | margin-right: 1em; 184 | margin-left: -100px; 185 | text-align: center; 186 | width: 40px; 187 | padding: 4px; 188 | border-radius: 1ex; 189 | -webkit-border-radius: 1ex; 190 | -moz-border-radius: 1ex; 191 | } 192 | 193 | address { 194 | text-align: right; 195 | } 196 | 197 | hr { 198 | margin-top: 3.5em; 199 | border-width: 1px; 200 | color: #fff; 201 | } 202 | 203 | .stylepoint_section { 204 | display: block; 205 | margin-bottom: 1em; 206 | color: #24597d; 207 | font-size: 90%; 208 | font-weight: bold; 209 | margin-left: -2%; 210 | } 211 | 212 | .stylepoint_subsection { 213 | color: #24597d; 214 | font-size: 90%; 215 | font-weight: bold; 216 | margin-left: -1%; 217 | } 218 | 219 | .stylepoint_subsubsection { 220 | color: #24597d; 221 | font-size: 80%; 222 | font-weight: bold; 223 | margin-left: 0; 224 | } 225 | 226 | .revision { 227 | text-align: right; 228 | } 229 | 230 | .comment_author { 231 | color: #3075A4; 232 | } 233 | 234 | .comment_barth { 235 | color: #660000; 236 | } 237 | 238 | @page { 239 | margin-left: 0; 240 | margin-right: 0; 241 | } 242 | @media print { 243 | body { 244 | font-size: 11pt; 245 | color: black; 246 | 247 | margin-left: 2cm; 248 | margin-right: 2cm; 249 | 250 | text-align: justify; 251 | } 252 | h2, .toc_title { 253 | margin-left: 0px; 254 | } 255 | h3, h4, h5, h6 { 256 | margin-left: 0px; 257 | } 258 | .stylepoint_section { 259 | margin-left: 0px; 260 | } 261 | .stylepoint_subsection { 262 | margin-left: 0px; 263 | } 264 | .cpp11_marker { 265 | margin-left: -17mm; 266 | margin-right: 0.5em; 267 | margin-top: 0; 268 | background: white; 269 | color: #1f4b69; 270 | } 271 | div.cpp11box { 272 | margin-right: -1cm; 273 | background: white; 274 | } 275 | div.cpp11Header { 276 | background: none; 277 | border-bottom: 1px solid #1f4b69; 278 | color: #1f4b69; 279 | } 280 | .showhide_button { 281 | display: none; 282 | } 283 | .link_button { 284 | display: none; 285 | visibility: hidden; 286 | } 287 | a { 288 | } 289 | a:link { 290 | text-decoration: none; 291 | color: black; 292 | } 293 | a:visited { 294 | text-decoration: none; 295 | color: black; 296 | } 297 | a:hover { 298 | text-decoration: none; 299 | color: black; 300 | } 301 | stylepoint_body { 302 | display: inline; 303 | } 304 | } 305 | --------------------------------------------------------------------------------