1## Contributing to Sol
2
3Looking to contribute to Sol? Well, first thing I want to mention is thank you!
4Second of all, this is probably where you should look :)
5
6## Reporting Issues
7
8If you found a bug, please make sure to make an issue in the issue tracker.
9
10The guidelines for reporting a bug are relatively simple and are as follows:
11
121. Produce a simple, short, compilable test case that reproduces your problem.
132. Make a descriptive title that summarises the bug as a whole.
143. Explain the bug in as much detail as you can in the body of the issue.
15
16If you have all of those requirements set, then your issue reporting is golden.
17
18## Submitting a pull request
19
20Submitting a pull request is fairly simple, just make sure it focuses on a single aspect and doesn't
21manage to have scope creep and it's probably good to go. It would be incredibly lovely if the style is
22consistent to those found in the repository.
23
24They are as follows (more will be added as they come up):
25
26- No spaces between parentheses. e.g. `f(g())` not `f ( g ( ) )`.
27- Tabs for indentation, spaces for alignment.
28- Bracing style is
29
30```cpp
31if(my_bool) {
32
33}
34else if(my_other_bool) {
35
36}
37else {
38
39}
40```
41
42- Variable names follow those in the C++ standard, basically snake_case.
43- Maximum column length is 125
44- Trailing return type will always be in the same line. Even if it goes off the column length. e.g.
45`auto f() -> decltype(/* my long expression */) {`
46- Since this is a header-only library, all free functions must be marked `inline`.
47- Use braces in optional contexts like `if`, `for`, `else`, `while`, etc. e.g.
48
49```cpp
50if(x > 12) {
51    return x * 2;
52}
53```
54
55- Use `typename` instead of `class` for template parameters. e.g. `template<typename T>`.
56
57If you don't meet all of these style guidelines, don't fret. I'll probably fix it. But please
58do make an effort to actually meet them. Otherwise I'm more likely to reject the pull request.
59