You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+23-22Lines changed: 23 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,41 +4,42 @@ First, thank you!
4
4
5
5
Writing esoteric scientific software can be it's own reward, but it's not for the faint of heart.
6
6
7
-
If you want a general overview as to why this software package exists, please look at my talk [Causal Dynamical Triangulations with CGAL][slides], or the [Wiki][2].
7
+
If you want a general overview as to why this software package exists, please look at my talk [Causal Dynamical Triangulations with CGAL][slides], or the [Wiki].
8
8
9
9
Second, here are some simple guidelines that will make it easier on me to process and accept your contributions.
10
10
11
11
1. Fork the repository.
12
-
2.Install GMock/GTest. See [.travis.yml][1] for details.
13
-
3. Write a unit test for your proposed contribution. Unit tests go in the `unittests` directory and are named \{YourContribution\}Test.cpp, so that they can be automatically built. All proposed features of your contribution should have a corresponding test in \{YourContribution\}Test.cpp. Consult the [GMock][3]and [GTest][4] documentation if you are unsure, or consult existing tests for examples. Prefer [predicate assertions][5] because their output is much easier to understand and useful for debugging.
14
-
4. I highly recommend writing your tests first, before your contribution, as this helps to think about how the rest of the program will use your functions and/or classes. This [Test-Driven Development][6] has saved me quite a lot from various mistakes.
12
+
2.Familiarize yourself with [Catch] and in particular, the [Gherkin] syntax.
13
+
3. Write a unit test for your proposed contribution. Unit tests go in the `tests` directory and are named \{YourContribution\}Test.cpp, so that they can be automatically built. All proposed features of your contribution should have a corresponding test in \{YourContribution\}Test.cpp. Consult the [Catch Test cases and sections]if you are unsure, or consult existing tests for examples.
14
+
4. I highly recommend writing your tests first, before your contribution, as this helps to think about how the rest of the program will use your functions and/or classes. This [Test-Driven Development] has saved me quite a lot from various mistakes.
15
15
5. Project source code goes into the `src` directory, generally as header files named \{YourContribution\}.h. This makes inclusion into tests and the main program easy and modular.
16
-
6. Don't forget documentation! It's helpful if you state explicitly what your functions and/or classes do. I use [Doxygen][7] to automatically build documentation, so using `/// @brief` and `/// @param[]` is helpful and easy. Consult existing code for examples.
17
-
7. Commit your changes with a clear, [well-written commit message][8]. _I am guilty of not always writing the clearest commit messages in this project, and will do better. For the longest time, however, no one but me actually read them. When I contribute to other projects, I definitely try to have useful, clear commit messages and you should, too._
16
+
6. Don't forget documentation! It's helpful if you state explicitly what your functions and/or classes do. I use [Doxygen] to automatically build documentation, so using `/// @brief` and `/// @param[]` is helpful and easy. Consult existing code for examples.
17
+
7. Commit your changes with a clear, [well-written commit message]. _I am guilty of not always writing the clearest commit messages in this project, and will do better. For the longest time, however, no one but me actually read them. When I contribute to other projects, I definitely try to have useful, clear commit messages and you should, too._
18
18
8. Run `clang-format` using `.clang-format` included with the project.
19
-
9. Open a pull request against the main repository. [Travis-CI][9] will test it against combinations of Linux (Ubuntu 14.04), MacOS, clang, and gcc, so ensure that your code compiles on both platforms with both compilers.
20
-
10. Look at the results from the [Valgrind][14] tests on [Travis-CI][9], which will tell you about any memory leaks or other subtle issues.
19
+
9. Open a pull request against the main repository. [Travis-CI] will test it against combinations of Linux (Ubuntu 14.04), MacOS, clang, and gcc, so ensure that your code compiles on both platforms with both compilers.
20
+
10. Look at the results from the [Valgrind] tests on [Travis-CI], which will tell you about any memory leaks or other subtle issues.
21
21
11. I will get to your change as soon as I can. You will receive proper credit for your contributions both in the code and any resulting scientific papers using the output of `git log --format='%aN | sort -u`.
22
22
23
23
### Style Guide ###
24
24
25
-
This project generally follows [Stroustrup formatting with Allman brackets][10], enforced by [`clang-format`][13] using the [.clang-format][11] configuration. We also test against the [C++ Core Guidelines][cpp-core] using [clang-tidy][clang-tidy-sh] with an appropriate configuration. Clang-tidy changes the code when run, so comparing results and running unit tests is recommended before you commit, especially since some of clang-tidy's fixes break the codebase (the script runs just the tests that don't).
25
+
This project generally follows [Stroustrup formatting with Allman brackets][1], enforced by [`clang-format`][2] using the [.clang-format][3] configuration. We also test against the [C++ Core Guidelines][cpp-core] using [clang-tidy][clang-tidy-sh] with an appropriate configuration. Clang-tidy changes the code when run, so comparing results and running unit tests is recommended before you commit, especially since some of clang-tidy's fixes break the codebase (the script runs just the tests that don't).
26
26
27
27
Most editors/IDEs have plugins for `clang-format` and `clang-tidy`.
0 commit comments