Skip to content
Antony Male edited this page Mar 10, 2015 · 9 revisions

Contributions, feature suggestions, and bug reports are more than welcome.

For bug reports, please open an issue. For feature suggestions, either open an issue or catch me on IRC (I hang out in ##csharp and #syncthing on freenode).

If you're planning on submitting code, thank you! If it's a medium or large feature, however, please talk to me first. Bug fixes are always welcome.

When submitting code, please create a new branch based off develop, and do your work on that branch. Clean up the branch if necessary using rebase -i before submitting it as a pull request. Changes discussed on the PR should be made to the same branch - feel free to rewrite history and force-push here.

Coding Standard

  • Namespaces, classes, methods, and public/protected properties should be in PascalCase.
  • Private fields should be in camelCase, unless they are the backing field for a property, in which case they should be in _camelCaseWithLeadingUnderscore.
  • this. should be used for all local method, property, and field access. Qualifying static access in the same manner is not required.
  • Public/protected fields are not allowed, and private properties are discouraged unless there's a good reason for them.
  • var is preferred for non-primitive types.
  • C# type aliases are used (rather than CLR types) for primitive type declarations, whereas CLR types are preferred when calling static methods. E.g. string foo = String.Format(...).
  • Fields should be readonly where possible.
  • Fields and properties should generally appear before constructors, and constructors appear before methods, but this can be broken if it aids readability (e.g. grouping a readonly lock object, a private backing field, and a public property).
  • Either all components of an if/else if/else structure should omit curly brackets, or none should.
  • Curly brackets should never be ommitted from loops or other control structures.
  • Multiple classes per file are permitted so long as they are closely related, and it aids readability (e.g. many small composed interfaces, an interface and the extension methods on it, or a small interface and its single implementation).
  • Inner classes and inner enums should always be private.
Clone this wiki locally