Follow the ideas of [a-successful-git-branching-model](http://nvie.com/posts/a-successful-git-branching-model), especially
- Create a new branch for all new features, following the naming convention `feature/XYZ`
Follow the ideas of [a-successful-git-branching-model](http://nvie.com/posts/a-successful-git-branching-model),
especially
- Create a new branch for all new features, following the naming convention
`feature/XYZ`
- Merge features in the `develop` branch only
- Correct Bugs in issue branches, following the naming convention `issue/XYZ`
- Merge issues in the `develop` branch, except when it is a hotfix, then merge to `master` and `develop`
- Merge issues in the `develop` branch, except when it is a hotfix, then merge
to `master` and `develop`
- For all merges create a meaningful *Merge Request* in GitLab
# Code Style-Guide
This style-guide is intended for developers writing code for AMDiS, is not complete and probably not applied to all parts of the AMDiS code. Feel free to edit existing source files in order to fulfill the styles.
This style-guide is intended for developers writing code for AMDiS, is not complete
and probably not applied to all parts of the AMDiS code. Feel free to edit existing
source files in order to fulfill the styles.
Parts of this convention are taken from well established style guides, like the *Google C++ Style Guide*.
Parts of this convention are taken from well established style guides, like the
*Google C++ Style Guide*.
In general, the code should follow the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines).
## File naming conventions
Filenames should be mixed lower and upper case, starting with an uppercase letter. They should not include underscores or dashed. Use an uppercase letter to indicate a new subword. Sourcefiles should end in `.cpp` and header files should end in `.hpp`. In case you move the code of a template class to a separate file, included textually at the end of the corresponding header file, use the extensions `.inc.hpp`.
Filenames should be mixed lower and upper case, starting with an uppercase letter.
They should not include underscores or dashed. Use an uppercase letter to indicate
a new subword. Sourcefiles should end in `.cpp` and header files should end in `.hpp`.
In case you move the code of a template class to a separate file, included textually
at the end of the corresponding header file, use the extensions `.inc.hpp`.
The name of a file should follow the name of the implemented class in this file.
...
...
@@ -26,21 +36,26 @@ Examples of valid filenames:
*`AdaptInstat.cpp`
*`DOFVector.hpp`
*`DOFVector.cpp`
*`DOFVector.inc.hpp` (the implementation of the methods of the template class `DOFVector<T>`)
*`DOFVector.inc.hpp` (the implementation of the methods of the template class
`DOFVector<T>`)
Do not use filenames that already exist in /usr/include or are stdandard C/C++ include files, such as `math.h` (remember that windows files-systems are case insensitive and thus, there is no difference between `math.h` and `Math.H`.)
Do not use filenames that already exist in /usr/include or are stdandard C/C++ include
files, such as `math.h` (remember that windows files-systems are case insensitive and
thus, there is no difference between `math.h` and `Math.H`.)
## Generale file structure
Every header file should start with a copyright notice and an include guard `#pragma once`, where the text of the copyright notice is given in the file `tools/license.templ.txt` and can automatically by added, using the script files in the `tools` directory:
Every header file should start with a copyright notice and an include guard `#pragma once`,
where the text of the copyright notice is given in the file `tools/license.templ.txt`
and can automatically by added, using the script files in the `tools` directory:
``` c++
// Software License for dune-amdis
// Software License for AMDiS
//
// Copyright (c) 2015 Institute for Scientific Computing, Technische Universitaet Dresden
// All rights reserved.
// Authors: Simon Praetorius
//
// This file is part of the dune-amdis Library
// This file is part of the AMDiS Library
// see also the LICENSE file in the distribution.
#pragma once
...
...
@@ -50,14 +65,18 @@ After the include guard a list of include files can be added, see *Names and Ord
### Names and Order of Includes
All of a project's header files should be listed as descendants of the project's source directory. The includes should be grouped following the rules:
* [class header file] ... for source files that implement an interface specified in a header file
All of a project's header files should be listed as descendants of the project's
source directory. The includes should be grouped following the rules:
* [class header file] ... for source files that implement an interface specified
in a header file
* C system files.
* C++ system files.
* Other external libraries' header files.
* Your project's header files.
For better readability a comment above each group can be added. Within each section the includes should be ordered alphabetically. Project's header files should be surrounded by `"`, while external header files should be surrounded by `<...>`.
For better readability a comment above each group can be added. Within each section
the includes should be ordered alphabetically. Project's header files should be
surrounded by `"`, while external header files should be surrounded by `<...>`.
For example, the includes in `io/VtkWriter.cpp` might look like this:
...
...
@@ -86,7 +105,8 @@ For example, the includes in `io/VtkWriter.cpp` might look like this:
### Namespaces
All implementation should be put into the namespace `AMDiS`. When a namespace closes, a corresponding comment should be added to the closing brackets:
All implementation should be put into the namespace `AMDiS`. When a namespace closes,
a corresponding comment should be added to the closing brackets:
``` c++
namespaceAMDiS
...
...
@@ -95,7 +115,9 @@ namespace AMDiS
}// end namespace AMDiS
```
Implementation details are put into a subnamespace `Impl`. A few more subnamespaces of `AMDiS` are allowed, e.g., `Concepts`. If onw of these subnamespaces need another subsubnamespace for implementation details, it should be names `_Impl`.
Implementation details are put into a subnamespace `Impl`. A few more subnamespaces
of `AMDiS` are allowed, e.g., `Concepts`. If one of these subnamespaces need another
subsubnamespace for implementation details, it should be named `Impl_`.
## Line length
...
...
@@ -112,4 +134,5 @@ Use two spaces instead of tabs!
## Documentation
Use Doxygen-Style comments for the documentation of functions and classes, except when the function name already indicates its meaning completely.
Use Doxygen-Style comments for the documentation of functions and classes, except
when the function name already indicates its meaning completely.
