1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
# Contributing to `elastix` #
**Thank you for considering contributing to `elastix`!**
### Do you have questions about the source code? ###
* Ask any question about how to use `elastix` on the [mailing list](https://groups.google.com/forum/#!forum/elastix-imageregistration).
* Do not open an issue on GitHub for general questions, registration questions, or issues you may have while running `elastix`. _GitHub issues are primarily intended for bug reports and fixes._
* General information about `elastix` can be found on our [wiki](https://github.com/SuperElastix/elastix/wiki) or at the [website](https://elastix.dev/).
* [The manual](https://github.com/SuperElastix/elastix/releases/download/5.0.0/elastix-5.0.0-manual.pdf) explains much of the inner workings of image registration.
### Did you find a bug? ###
* _Ensure the bug was not already reported_ by searching on GitHub under [Issues](https://github.com/SuperElastix/elastix/issues).
* If you're unable to find an open issue addressing the problem, you can [open a new one](https://github.com/SuperElastix/elastix/issues/new). Be sure to include a _title and clear description_, as much relevant information as possible. A _code sample with a test_ demonstrating the expected behavior that is not occurring would be awesome.
### Do you intend to add a new feature or change an existing one? ###
* Suggest your change on the `elastix` mailing list.
* Do not open an issue on GitHub until you have collected positive feedback about the change.
### Did you write a patch that fixes a bug? ###
* Open a new [GitHub pull request](https://github.com/SuperElastix/elastix/pull/new/main) (PR) with the patch.
* Make sure the PR is done with respect to the [main branch](https://github.com/SuperElastix/elastix/tree/main).
* Ensure the PR description (log message) _clearly describes the problem and solution_. Include the relevant issue number if applicable. One-line messages are fine for small changes, but bigger changes should look like this:
$ git commit -m "ENH: A brief summary of the commit
>
> A paragraph describing what changed and its impact."
* We use the following tags for commit messages:
- ENH: for functional enhancements of the code
- BUG: for fixing runtime issues (crash, segmentation fault, exception, or incorrect result)
- COMP: for compilation issues (error or warning)
- PERF: for performance improvements
- STYLE: a change that does not impact the logic or execution of the code (improve coding style, comments, documentation)
The body of the message should clearly describe the motivation of the commit
(**what**, **why**, and **how**). In order to ease the task of reviewing
commits, the message body should follow the following guidelines:
1. Leave a blank line between the subject and the body.
This helps `git log` and `git rebase` work nicely, and allows to smooth
generation of release notes.
2. Try to keep the subject line below 73 characters.
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood in the subject line (e.g. `BUG: Add missing spacing`).
6. Use semantic line feeds to separate different ideas, which improves the
readability.
7. Be concise, but honor the change: if significant alternative solutions
were available, explain why they were discarded.
8. If the commit refers to a topic discussed in elastix' mailing list, or fixes
a regression test, provide the link. If it fixes a compiler error, provide a
minimal verbatim message of the compiler error. If the commit closes an
issue, use the [GitHub issue closing
keywords](https://help.github.com/en/articles/closing-issues-using-keywords).
Keep in mind that the significant time is invested in reviewing commits and
*pull requests*, so following these guidelines will greatly help the people
doing reviews.
These guidelines are largely inspired by Chris Beam's
[How to Write a Commit Message](https://chris.beams.io/posts/git-commit/)
post.
* After cloning the repository, run the `./tools/pre-commit-setup.bash` script to install the pre-commit hook. This hook will check the code format with clangFormat before committing. If the hook fails, the commit will be aborted. The hook can be used locally, for details see below.
* Ensure the PR adheres to our [coding conventions](#coding-conventions), the PR code format will be checked with clangFormat on the CI. The hook can be used locally, for details see below.
* We will review your PR and possibly suggest changes. All PR will be tested on the GitHub Actions CI. When all lights are green, the PR will be merged.
* More information on pull requests can be found [here](https://help.github.com/articles/creating-a-pull-request/) and [here](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
<!--
### **Do you want to contribute to the `elastix` documentation?*
* Please read [Contributing to the Rails Documentation](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#contributing-to-the-rails-documentation).
-->
## Coding conventions ##
Start reading our code and you'll get the hang of it. We optimize for readability:
* We indent using two spaces (soft tabs). This ensures a consistent layout of the code on different text editors.
* We ALWAYS put spaces after list items and function arguments (`[1, 2, 3]`, not `[1,2,3]`), around operators (`x += 1`, not `x+=1`), etc.
* Use `/** ... */` style documentation.
* Member variables of classes should start their name with `m_`. For example: `m_NumberOfIterations`.
* Type definitions should start with a capital. ImageType for example, instead of imageType.
* This is open source software. Consider the people who will read your code, and make it look nice for them. It's sort of like driving a car: Perhaps you love doing donuts when you're alone, but with passengers the goal is to make the ride as smooth as possible.
## Code of conduct ##
Please respect our [code of conduct](CODE_OF_CONDUCT.md).
Thanks,
The `elastix` team
|
