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
90a18f93
Commit
90a18f93
authored
Apr 14, 2015
by
Matthias Vallentin
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Adapt contribution guidelines
parent
eacae4a5
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
82 additions
and
72 deletions
+82
-72
CONTRIBUTING.md
CONTRIBUTING.md
+82
-72
No files found.
CONTRIBUTING.md
View file @
90a18f93
This document specifies the coding style for the C++ Actor Framework.
This document specifies how to contribute code to this repository.
The style is loosely based on the
[
Google C++ Style Guide
](
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
)
and the coding conventions used by the STL.
Git Workflow
============
CAF's git workflow encompasses the following key aspects. (For general git
style guidelines, see https://github.com/agis-/git-style-guide.)
-
The
`master`
branch always reflects a
*production-ready*
state, i.e.,
the latest release version.
-
The
`develop`
branch is the main development branch. A maintainer merges into
`master`
for a new release when it reaches a stable point. The
`develop`
branch reflects the latest state of development and should always compile.
-
Simple bugfixes consisting of a single commit can be pushed to
`develop`
.
-
Fixes for critical issues can be pushed to
`master`
(and
`develop`
)
after talking to a maintainer (and then cause a new release immediately).
-
For new features and non-trivial fixes, CAF uses
*topic branches*
which
branch off
`develop`
with a naming convention of
`topic/short-description`
.
After completing work in a topic branch, check the following steps to prepare
for a merge back into
`develop`
:
+
Squash your commits into a single one if necessary
+
Create a pull request to
`develop`
on github
+
Wait for the results of Jenkins and fix any reported issues
+
Ask a maintainer to review your work after Jenkins greelights your changes
+
Address the feedback articulated during the review
+
A maintainer will merge the topic branch into
`develop`
after it passes the
code review
Commit Message Style
--------------------
-
The first line succintly summarizes the changes in no more than 50
characters. It is capitalized and written in and imperative present tense:
e.g., "Fix bug" as opposed to "Fixes bug" or "Fixed bug".
-
The second line is empty.
-
Optional long descriptions as full sentences begin on the third line,
indented at 72 characters per line.
Coding Style
============
When contributing source code, please adhere to the following coding style,
whwich is loosely based on the
[
Google C++ Style
Guide
](
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
)
and the
coding conventions used by the STL.
Example for the Impatient
Example for the Impatient
=========================
-------------------------
```
cpp
```
cpp
// libcaf_example/caf/example/my_class.hpp
// libcaf_example/caf/example/my_class.hpp
...
@@ -135,7 +187,7 @@ void::my_class::do_something_else() {
...
@@ -135,7 +187,7 @@ void::my_class::do_something_else() {
General rules
General rules
=============
-------------
-
Use 2 spaces per indentation level.
-
Use 2 spaces per indentation level.
...
@@ -204,7 +256,7 @@ General rules
...
@@ -204,7 +256,7 @@ General rules
Naming
Naming
======
------
-
Class names, constants, and function names are all-lowercase with underscores.
-
Class names, constants, and function names are all-lowercase with underscores.
...
@@ -251,7 +303,7 @@ Naming
...
@@ -251,7 +303,7 @@ Naming
Headers
Headers
=======
-------
-
Each
`.cpp`
file has an associated
`.hpp`
file.
-
Each
`.cpp`
file has an associated
`.hpp`
file.
Exceptions to this rule are unit tests and
`main.cpp`
files.
Exceptions to this rule are unit tests and
`main.cpp`
files.
...
@@ -277,7 +329,7 @@ Headers
...
@@ -277,7 +329,7 @@ Headers
Breaking Statements
Breaking Statements
===================
-------------------
-
Break constructor initializers after the comma, use four spaces for
-
Break constructor initializers after the comma, use four spaces for
indentation, and place each initializer on its own line (unless you don't
indentation, and place each initializer on its own line (unless you don't
...
@@ -315,7 +367,7 @@ Breaking Statements
...
@@ -315,7 +367,7 @@ Breaking Statements
Template Metaprogramming
Template Metaprogramming
========================
------------------------
Despite its power, template metaprogramming came to the language pretty
Despite its power, template metaprogramming came to the language pretty
much by accident. Templates were never meant to be used for compile-time
much by accident. Templates were never meant to be used for compile-time
...
@@ -361,7 +413,7 @@ extra rules for formatting metaprogramming code.
...
@@ -361,7 +413,7 @@ extra rules for formatting metaprogramming code.
Rvalue References
Rvalue References
=================
-----------------
-
Use rvalue references whenever it makes sense.
-
Use rvalue references whenever it makes sense.
...
@@ -369,51 +421,9 @@ Rvalue References
...
@@ -369,51 +421,9 @@ Rvalue References
Preprocessor Macros
Preprocessor Macros
===================
-------------------
-
Use macros if and only if you can't get the same result by using inline
-
Use macros if and only if you can't get the same result by using inline
functions or proper constants.
functions or proper constants.
-
Macro names use the form
`CAF_<COMPONENT>_<NAME>`
.
-
Macro names use the form
`CAF_<COMPONENT>_<NAME>`
.
General Git Rules
=================
-
The first line is a capitalized summary and has at most 50 characters.
-
The second line is left empty.
-
Optional long descriptions begin on the third line with a at most 72
characters per line.
-
Write commit messages in the imperative: "Fix bug" and not "Fixes bug"
or "Fixed bug".
Git Branches and Work Flow
==========================
-
The
`master`
branch always reflects a
*production-ready*
state, i.e.,
the latest release version.
-
The
`develop`
branch is the main branch. Every time it reaches a stable
point it is merged back to
`master`
for a new release. The
`develop`
branch
reflects the latest state of development and should always compile.
-
Simple bugfixes consisting of a single commit can be pushed to
`develop`
.
-
Fixes for critical issues can be pushed to the
`master`
(and
`develop`
)
branch after talking to the maintainer
(and then cause a new release immediately).
-
New features or non-trivial fixes are developed in a
*topic branch*
using
the naming convention
`topic/short-description`
. Topic branches are merged
off from
`develop`
. Finishing topic branches includes these steps:
+
Create a
*pull request*
to
`develop`
on GitHub
+
Wait for the results of Jenkins and fix any issues that might come up
+
Squash your commits if necessary once Jenkins succeeds
+
Ask the maintainer to review your changes if you have green light from
Jenkins and a clean Git history for your work
+
The maintainer will merge the topic branch back into
`develop`
after the
review phase is done (and you once again have a clean Git history)
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