Skip to content

Latest commit

 

History

History
76 lines (43 loc) · 4.06 KB

CONTRIBUTING.md

File metadata and controls

76 lines (43 loc) · 4.06 KB

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. You can subscribe to the mailing list here, after which you can email to [email protected].

  • 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 website.

  • The manual 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.

  • If you're unable to find an open issue addressing the problem, you can open a new one. 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 (PR) with the patch.

  • Make sure the PR is done with respect to the develop branch.

  • 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)

  • Ensure the PR adheres to our coding conventions.

  • We will review your PR and possibly suggest changes. We also have an automatic build and test system checking all PRs (Travis-CI). When all lights are green, the PR will be merged.

  • More information on pull requests can be found here and here.

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.

Thanks,
The elastix team