This project is read-only.

Coding Guidelines

In general, we will follow the accepted standards for coding in c#. I recently referred to this document as an example. Below comments are in-house variants or simply to re-iterate standards.
Please feel free to edit this document and post your comments


  • If you meet a problem, or don't know how to do something, first do a search on the internet ;-) then post in discussion or issue tracker

Understanding the code base

  • ApplicationManager holds everything related to displaying screens, input, sound etc.
    • Gameflow revolves around push and popping screens off the screen
  • GameManager holds everything related to the game itself
  • DungeonScreen holds everything related to the in game UI
  • Rulesets hold the logic for the game
  • Helpers do just about everything
  • Data and Content are held in separate projects.
  • Check out the Documentation packaged with the source code for more information

Submitting Code

  • If you have not yet joined, you can submit a code change as a patch.
  • Keep your changes small and limited to one or two classes if you want them added
  • Ask to join if you want to submit your code via SVN
  • Create a branch from the trunk with your username and make your changes there
    • Branches under a username will be considered private
    • If you prefer to collaborate on a branch, put it directly in the branches folder
  • Commit often and always leave a comment, especially if you expect feedback or want your code to be included in the main trunk.
  • After review, your changes maybe integrated into the main trunk and make the next release


  • Find a task under the issue tracker that isn't assigned or has been inactive for > one month and assign it to yourself.
  • If you change something with no active task, add a task to the issue tracker and close it with a comment. Make sure to select the correct version number. This will be used to update the change log.


  • use three slashes /// to comment directly above your code to add notes to the auto documentation.
  • use //TODO: to mark code that needs writing
  • use //FIX: to mark code that needs repairing
  • use// HACK: to mark hard code or a temporary fix that needs updating

Neat code

  • use regions (#region <name>, #endregion) to encapsulate public and private variables, properties and methods.
  • tidy and comment the code base when you review it.

Naming methods

  • use long descriptive names for methods
  • for private variables use camelScript
  • for public use PascalScript

Agile Development

  • just do it
  • test it
  • document it

TDD (Test Driven Development)

  • write a test before you write the code
  • write your code to pass the test
  • try to predict and catch errors before they happen
  • play test thoroughly


  • first create a branch and test your code before re-merging to trunk

Last edited May 5, 2013 at 2:58 AM by asads2012, version 16


dommillar Aug 2, 2012 at 3:36 PM 
ASADS2012 - sorry I didn't comment earlier on this - this is excellent!!!!