oliverbooth/X10D
oliverbooth/X10D
1
0
Fork 0
mirror of https://github.com/oliverbooth/X10D synced 2024-11-10 03:25:41 +00:00
Code Issues

[ci skip] Merge branch 'develop'

Browse Source
This commit is contained in:
Oliver Booth 2022-04-30 16:56:47 +01:00
commit 5ad510a688
No known key found for this signature in database
GPG Key ID: 32A00B35503AF634
1 changed files with 24 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
CONTRIBUTING.md
View File

@ -1,29 +1,43 @@
## How you can contribute ## How you can contribute
Contributions to this project are always welcome. If you spot a bug, or want to request a new extension method, open a new issue or submit a pull request.
Contributions to this project are always welcome. If you spot a bug, or want to request a new extension method, open a new issue
or submit a pull request.
### Pull request guidelines ### Pull request guidelines
This project uses C# 9.0 language features, and adheres to the FxCop analyzer.
There is an `.editorconfig` included in this repository. For quick and painless pull requests, ensure that the analyzer does not throw warnings. This project uses C# 10.0 language features, and adheres to StyleCop rules with some minor adjustments.
There is an `.editorconfig` included in this repository. For quick and painless pull requests, ensure that the analyzer does not
throw warnings.
### Code style ### Code style
Below are a few pointers to which you may refer, but keep in mind this is not an exhaustive list: Below are a few pointers to which you may refer, but keep in mind this is not an exhaustive list:
- Use C# 9.0 features where possible - Use C# 10.0 features where possible
- Try to ensure code is CLS-compliant. Where this is not possible, decorate methods with `CLSCompliantAttribute` and pass `false` - Try to ensure code is CLS-compliant. Where this is not possible, decorate methods with `CLSCompliantAttribute` and pass `false`
- Follow all .NET guidelines for naming conventions - Follow all .NET guidelines and coding conventions.
See https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
and https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/
- Make full use of XMLDoc and be thorough - but concise - with all documentation - Make full use of XMLDoc and be thorough - but concise - with all documentation
- Ensure that no line exceeds 130 characters in length - Ensure that no line exceeds 130 characters in length
- Do NOT include file headers in any form - Do NOT include file headers in any form
- Declare `using` directives outside of namespace scope - Declare `using` directives outside of namespace scope
- Avoid using exceptions for flow control where possible - Avoid using exceptions for flow control where possible
- Use braces, even for single-statement bodies - Use braces, even for single-statement bodies
- Use implicit type when the type is apparent or not important - Use implicit type when the type is apparent
- Use explicit type otherwise
- Use U.S. English throughout the codebase and documentation - Use U.S. English throughout the codebase and documentation
When in doubt, follow .NET guidelines for styling. When in doubt, follow .NET guidelines.
### Tests ### Tests
When introducing a new extension method, you must ensure that you have also defined a unit test that asserts its correct behavior. The code style guidelines and code-analysis rules apply to the `X10D.Tests` equally as much as `X10D`, although documentation may be briefer. Refer to existing tests as a guideline.
When introducing a new extension method, you must ensure that you have also defined a unit test that asserts its correct behavior.
The code style guidelines and code-analysis rules apply to the `X10D.Tests` equally as much as `X10D`, although documentation may
be briefer. Refer to existing tests as a guideline.
### Disclaimer ### Disclaimer
In the event of a code style violation, a pull request may left open (or closed entirely) without merging. Keep in mind this does not mean the theory or implementation of the method is inherently bad or rejected entirely (although if this is the case, it will be outlined)
In the event of a code style violation, a pull request may left open (or closed entirely) without merging. Keep in mind this does
not mean the theory or implementation of the method is inherently bad or rejected entirely (although if this is the case, it will
be outlined)