Contributing

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

• For bug reports, please open an issue. For feature suggestions, please note that SyncTrayzor is currently maintenance-only. I will still accept reviews for new features, though.
• For help with SyncTrayzor or other discussions about the project, the "Discussions" tab on GitHub is a suitable place.
• For help with Syncthing itself, the syncthing community forums (https://forum.syncthing.net/) is where you want to go.
• If you want to talk to me directly, probably do so via the private message feature on the syncthing forum. My profile

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 main, and do your work on that branch. Clean up the branch if necessary using git 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.

Changes will usually be squashed on merge, so feel free to create as many commits as you need.

Coding Standard

Important

The list below used to be the old coding standard from 10+ years ago. It has changed several times since then and currently style is unfortunately not consistent. The current recommendation is to use modern C# conventions (such as those suggested by csharpier).

• 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.