Coding Guidelines

In order to provide maintainable code that we can all work from, we need to follow these c# guidelines:

• Fields are to be private, protected (or in rare cases “internal”), make public properties if you need to expose values to other classes.
• Fields should be prefixed like so: _backingStore
• Use PascalCase for Properties and Functions
• Include a <summary> for all public members (and ideally also for internal and protected members, too)
  • A corollary to this rule is to include a <summary> on class definitions – remember, if you can’t think of a brief overview of what the class or member is doing, it’s doing too much.
• Include <remarks> when something has gotchas, or there are things that might potentially break easily/aren’t implemented.
• Parameter and locally scoped variables should be camelCased
  • avoid i,j,k, etc… – intellisense is your friend.
• Keep names concise but adequately descriptive.
• Don’t make things public/internal that can be protected or even private – reduce surface area of class definitions to the minimum required.
• using statements are the first thing in all files. namespaces are second.
• Don’t use magic numbers/strings, declare and use consts instead.
• New code, new tests.
• For new feature sets, please create topic branches in your repo.
  • “git checkout -b <name of feature>” is the form to create a new topic branch.
  • “git pull <remote name> <remote branch>” will get you caught up with an external repo, please merge off of atheken’s master before sending a pull request.

These are guidelines that we should try to stick with, understanding that we’re all a little bit different about our habits, please send feedback to the google group