Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
A
Actor Framework
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Metrics
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
cpp-libs
Actor Framework
Commits
3a77d2f7
Commit
3a77d2f7
authored
Jul 22, 2014
by
Dominik Charousset
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Reorganize HACKING guide
parent
8a03aad0
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
91 additions
and
22 deletions
+91
-22
HACKING.md
HACKING.md
+91
-22
No files found.
HACKING.md
View file @
3a77d2f7
...
...
@@ -2,11 +2,12 @@ This document specifies the coding style for the C++ Actor Framework.
The style is based on the
[
Google C++ Style Guide
](
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
)
.
# Example for the Impatient
#### `libcaf_example/caf/example/my_class.hpp`
Example for the Impatient
=========================
```
cpp
// libcaf_example/caf/example/my_class.hpp
#ifndef CAF_EXAMPLE_MY_CLASS_HPP
#define CAF_EXAMPLE_MY_CLASS_HPP
...
...
@@ -66,9 +67,9 @@ class my_class {
#endif // CAF_EXAMPLE_MY_CLASS_HPP
```
#### `libcaf_example/src/my_class.cpp`
```
cpp
// libcaf_example/src/my_class.cpp
#include "caf/example/my_class.hpp"
#include <iostream>
...
...
@@ -112,33 +113,47 @@ void my_class::do_something() {
```
# General rules
General rules
=============
-
Use 2 spaces per indentation level.
-
The maximum number of characters per line is 80.
-
Never use tabs.
-
Vertical whitespaces separate functions and are not used inside functions:
use comments to document logical blocks.
-
Header filenames end in
`.hpp`
, implementation files end in
`.cpp`
.
-
Member variables use the prefix
`m_`
.
-
Thread-local variables use the prefix
`t_`
.
-
Never declare more than one variable per line.
-
`*`
and
`&`
bind to the
*type*
.
-
Class names, constants, and function names are all-lowercase with underscores
.
-
Template parameter names use CamelCase.
-
`*`
and
`&`
bind to the
*type*
, e.g.,
`const std::string& arg`
.
-
Namespaces do not increase the indentation level.
-
Access modifiers, e.g.
`public`
, are indented one space.
-
Use the order
`public`
,
`protected`
, and then
`private`
.
-
Always use
`auto`
to declare a variable unless you cannot initialize it
immediately or if you actually want a type conversion. In the latter case,
provide a comment why this conversion is necessary.
-
Never use unwrapped, manual resource management such as
`new`
and
`delete`
.
-
Do not use
`typedef`
. The syntax provided by
`using`
is much cleaner.
-
Use
`typename`
only when referring to dependent names.
-
Keywords are always followed by a whitespace:
`if (...)`
,
`template <...>`
,
`while (...)`
, etc.
-
Always use
`{}`
for bodies of control structures such as
`if`
or
`while`
,
even for bodies consiting only of a single statement.
-
Opening braces belong to the same line:
```
cpp
...
...
@@ -148,6 +163,7 @@ void my_class::do_something() {
my_other_fun
();
}
```
-
Use standard order for readability: C standard libraries, C++ standard
libraries, other libraries, (your) CAF headers:
```
cpp
...
...
@@ -161,26 +177,76 @@ void my_class::do_something() {
#include "caf/example/myclass.hpp"
```
# Headers
-
When declaring a function, the order of parameters is: inputs, then outputs.
-
Never use C-style casts.
Naming
======
-
Class names, constants, and function names are all-lowercase with underscores.
-
Types and variables should be nouns, while functions performing an action
should be "command" verbs. Classes used to implement metaprogramming
functions also should use verbs, e.g.,
`remove_const`
.
-
Member variables use the prefix
`m_`
.
-
Thread-local variables use the prefix
`t_`
.
-
Static, non-const variables are declared in the anonymous namespace
and use the prefix
`s_`
.
-
Template parameter names use CamelCase.
-
Getter and setter use the name of the member without the
`m_`
prefix:
```
cpp
class
some_fun
{
public:
// ...
int
value
()
const
{
return
m_value
;
}
void
value
(
int
new_value
)
{
m_value
=
new_value
;
}
private:
int
m_value
;
};
```
Headers
=======
-
Each
`.cpp`
file has an associated
`.hpp`
file.
Exceptions to this rule are unit tests and
`main.cpp`
files.
-
Each class has its own pair of header and implementation
files and the relative path is derived from its full name.
For example, the header file for
`caf::example::my_class`
of
`libcaf_example`
is located at
`libcaf_example/caf/example/my_class.hpp`
.
Source files simply belong to the
`src`
folder of the component, e.g.,
`libcaf_example/src/my_class.cpp`
.
-
All header files should use
`#define`
guards to prevent multiple inclusion.
The symbol name is
`<RELATIVE>_<PATH>_<TO>_<FILE>_HPP`
.
-
Do not
`#include`
when a forward declaration suffices.
-
Each library component must provide a
`fwd.hpp`
header providing forward
declartations for all types used in the user API.
-
Each library component must provide an
`all.hpp`
header including
all headers for the user API and the main page for the documentation.
-
Each library component must provide an
`all.hpp`
header that contains
main page for the documentation and includes all headers for the user API.
-
Use
`inline`
for small functions (rule of thumb: 10 lines or less).
## Template Metaprogramming
Template Metaprogramming
========================
Despite its power, template metaprogramming came to the language pretty
much by accident. Templates were never meant to be used for compile-time
...
...
@@ -191,9 +257,11 @@ extra rules for formatting metaprogramming code.
-
Brake
`using name = ...`
statements always directly after
`=`
if it
does not fit in one line.
-
Consider the
*semantics*
of a metaprogramming function. For example,
`std::conditional`
is an if-then-else construct. Hence, place the if-clause
on its own line and do the same for the two cases.
-
Use one level of indentation per "open" template and place the closing
`>`
,
`>::type`
or
`>::value`
on its own line. For example:
```
cpp
...
...
@@ -212,28 +280,29 @@ extra rules for formatting metaprogramming code.
else
(
optional
<
result_type
>
)
};
```
-
Note that this is not necessary when simply defining a type alias.
When dealing with "ordinary" templates, indenting based on the position of
the opening
`<`
is ok
too
, e.g.:
the opening
`<`
is ok, e.g.:
```
cpp
using
response_handle_type
=
response_handle
<
Subtype
,
message
,
ResponseHandleTag
>
;
```
# Miscellaneous
## Rvalue references
Rvalue references
=================
-
Use rvalue references whenever it makes sense.
-
Write move constructors and assignment operators if possible.
## Casting
-
Write move constructors and assignment operators if possible.
-
Never use C-style casts.
## Preprocessor Macros
Preprocessor Macros
===================
-
Use macros if and only if you can't get the same result by using inline
functions or proper constants.
-
Macro names use the form
`CAF_<COMPONENT>_<NAME>`
.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment