Skip to content
Snippets Groups Projects
Commit 73513f33 authored by Praetorius, Simon's avatar Praetorius, Simon
Browse files

Correct some typos in CONTRIBUTING.md

parent 7837b2b4
No related branches found
No related tags found
No related merge requests found
......@@ -6,7 +6,7 @@ Follow the git workflow:
- Correct Bugs in issue branches, following the naming convention `issue/XYZ`
- For features and issues *Merge Request* into the master branch should be created in GitLab
- Do not push into `master` directly
- Releases are created in a new branch `release/VERSION` that is not deleted after merged into master.
- Releases are created in a new branch `releases/VERSION` that is not deleted after merged into master.
After the merge, a tag with name `vVERSION` should be created.
# Code Style-Guide
......@@ -22,7 +22,7 @@ In general, the code should follow the [C++ Core Guidelines](https://github.com/
## File naming conventions
Filenames should be mixed lower and upper case, starting with an uppercase letter.
Filenames should be mixed lower and upper case (CamelCase), 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
......@@ -38,7 +38,7 @@ Examples of valid filenames:
* `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
Do not use filenames that already exist in /usr/include or are standard 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`.)
......@@ -46,7 +46,7 @@ thus, there is no difference between `math.h` and `Math.H`.)
### Names and Order of Includes
All of a project's header files should be listed as descendants of the project's
All of the 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
......@@ -77,8 +77,8 @@ For example, the includes in `io/VtkWriter.cpp` might look like this:
#include <boost/filesystem/operations.hpp>
// AMDiS headers
#include "AdaptInfo.hpp"
#include "DOFVector.hpp"
#include <amdis/AdaptInfo.hpp>
#include <amdis/DOFVector.hpp>
// ...
```
......@@ -96,7 +96,7 @@ namespace AMDiS
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_`.
subsubnamespace for implementation details, it should be named `Impl_` or `Impl2`.
## Formatting
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment