This page serves to document the practices used in developing this project.

As of right now, things are still open to suggestion -- it's a wiki, edit away.

GitHub facilities

The issue tracker

• If you see something that you would like to see changed, open an issue on the issue tracker.
• At the issue tracker page, we can then discuss specifics, implementation details and progress.
• When you want to start work on a feature, assign it to yourself so no double work is done. Work on larger features in a separate branch as explained below.

The wiki

Larger design documents and explanations of mechanics can go on here.

Source control

Commit early, commit often -- we have branches to stop junk from getting in other people's way. Roughly speaking, commit for every change after which the code compiles again.

Branches

There are two main branches:

• master (the release branch)
• dev (the development branch)

dev is merged into master whenever we feel the codebase is reasonably stable and free of bugs.

Aside from this, for larger changes it's useful to set up a separate branch, so partial implementations don't get in other people's way. This goes as follows:

• Check out a new branch from dev, with a name related to the issue you'll fix in there
• Plod away, committing often as noted above.
• When you are done, merge the branch back into dev (making sure any new code that has been added to it since stays working).

Code formatting

• Indentation should be four spaces per level. Tabs are too variable, and eight spaces is too long for deep nesting.
• Opening brace on the same line as whatever statement starts the block
• Line length is not a super big deal, but try to stay under 80 characters where you can.
• Capitalisation goes as follows:
  • Enum values and macros are ALL_UPPERCASE
  • Class names use InitialCaps
  • Class members use camelCase
  • local variables use all_lowercase