search

dennisdoomen / CSharpGuidelines

A set of coding guidelines for C# 9.0, design principles and layout rules for improving the overall quality of your code development.
https://www.csharpcodingguidelines.com
Other
746 stars 271 forks source link

AV2201 static member access #223

Closed bkoelman closed 3 years ago

bkoelman commented 3 years ago

Fixes #218.

bkoelman commented 3 years ago

Side note: I see that 'develop' is the default branch, while all recent changes have been done in master (it is 41 commits ahead). I remember from the past you liked to use GitFlow, but to me it only adds confusion. When I go to the repo, it shows me an outdated version. Given there's limited changes in this repo, wouldn't it be easier to just have a single master branch without develop?

dennisdoomen commented 3 years ago

Side note: I see that 'develop' is the default branch, while all recent changes have been done in master (it is 41 commits ahead). I remember from the past you liked to use GitFlow, but to me it only adds confusion. When I go to the repo, it shows me an outdated version. Given there's limited changes in this repo, wouldn't it be easier to just have a single master branch without develop?

Yeah, you might be right. I was trying to make breaking changes explicit by using semantic versioning.

dennisdoomen commented 3 years ago

But this PR is kind of a breaking change since it is the opposite of what we said before. How should we deal with that?

bart-degreed commented 3 years ago

Except for spelling corrections, changes to the website generation process and rendered layout, all textual changes are breaking. Adding a new rule breaks all codebases that didn't utilize that rule before. The same for adding an exception to an existing rule. I find the concept of semantic versioning and whether changes are considered breaking of limited use in this repo, because it does not affect binary dependencies. Likewise it makes no sense to deprecate a rule to remove it in the next major version, because removing rules is non-breaking in itself. I'm reasoning from the point of view of a team that needs to adhere to them.

It seems more similar to versioning design documents such as W3C, IEEE etc, where it is common practice to increment the minor version periodically as details are being refined, while major version increments are used for complete redesigns.