Skip to content

Latest commit

 

History

History
76 lines (45 loc) · 3.27 KB

CONTRIBUTING.md

File metadata and controls

76 lines (45 loc) · 3.27 KB
Raw

Contributing

You'd like to help make GameMath even more awesome? Seems like today's our lucky day! In order to maintain stability of the library and its code base, please adhere to the following steps, and we'll be pleased to include your additions in our next release.

Note that GameMath is distributed under the MIT License. So will be your code.

Step 1: Choose what to do

If you've got no idea how to help, head over to our issue tracker and see what you'd like to do most. You can basically pick anything you want to, as long as it's not already assigned to anyone.

If you know exactly what you're missing, open a new issue to begin a short discussion about your idea and how it fits the project. If we all agree, you're good to go!

Step 2: Fork the project and check out the code

GameMath is developed using the GitFlow branching model. In order to contribute, you should check out the latest develop branch, and create a new feature or hotfix branch to be merged back.

Step 3: Implement your feature or bugfix

We recommend using StyleCop for verifying your code against our coding guidelines.

Algorithm Implementation Conventions

If you are implementing a non-trivial algorithm (think: non-trivial for others, not for you), you should

  • add a link to the source in the remarks,
  • write unit tests verifying your implementation,

or both.

Algorithm classes should not be static. This allows for providing common interfaces in the future, and easier mocking and/or replacement in that case.

Type Implementation Conventions

Data types should be immutable where it makes sense.

Data types must always provide the following operations:

  • Equals
  • GetHashCode
  • ==
  • !=
  • ToString

All types must be CLS-compliant.

Documentation Conventions

All types and members must have full XML comment documentation, including the following tags (where appropriate):

  • Summary
  • Remarks
  • Param
  • Returns
  • Exception
  • SeeAlso

Naming Conventions

In order to make the code more readable and consistent, contributions are required to adhere to the following guidelines:

  • Vectors are denoted by v, w, u.

  • Pairs of vectors are denoted by v, w (as opposed to v0, v1).

  • Points are denoted by p, q, r, s.

  • Pairs of points are denoted by p, q (as opposed to p0, p1).

  • Numbers without meaning are denoted by x, y, z.

  • Numbers with meaning are denoted by their meaning (e.g. degrees).

  • Pairs of any other type are denoted by first, second.

Exceptions to these rules are algorithms implemented based on public sources. If your implementation is based on a publication using different symbols, you should use these names in order to increase readability with respect to the original source.

Step 4: Open a pull request

Finally, open a pull request so we can review your changes together, and finally integrate it into the next release.