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 large-ish 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 you work on that branch. Clean up the branch if necessary using rebase -i before submitting it as a pull request.

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.
  • 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 is 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.
  • All public and protected members should be fully documented. Documentation for private and internal members is optional.
Clone this wiki locally