Make the following changes on the develop branch
General
Update version numbers to C# 14
Update cheat sheet
Introduction
Add something about the use of AI. E.g. using is fine, as long as you treat all that code as your own
Replace ".NET Framework" with just .NET
Mention my .NET Starter Kit as a good companion
Mention that this guideline is also used by all my open-source projects
Explain to apply DRY within boundaries, but duplicate code across boundaries when it's simple
Add the most critical coding guidelines on your PR template
Check all links to see if they point to valid files
Rider has a file structure window as well
Mention all my open-source projects and how they influenced the guidelines
Remove Gitter reference
Update social media links
Mention the many Roslyn analyzers and how directory.props can be used
General Guidelines
New: Understand the boundaries of your code base
New: Use design patterns to refactor code into a structure people can recognize by name
New: Prefer compoisiton over inheritance
Class Design Guidelines: Rename to "Type Design Guidelines" or "Class/Record Design Guidelines"
AV1000
Tip: If you can't find a good name for a class, or struggle to document, it's doing to much.
Tip: If you explain what the class does to an AI, it may help detect multiple responsibilities
For primitive types, consider an immutable record type
AV1001?: Only pass things to a constructor that most or all members need
AV1003: Avoid taking the name of the class and slapping an I in front of it
Consider using role-based names like IFetchSomething or IProvideClusterwideLock
AV1004: Typo in "a(n abstract)"
AV1005: Understand the boundaries of your code base. Use interfaces across boundaries, but avoid them within the boundary
AV1013: Rephrase as "Don't cast a base class to one of its derived classes". Also add an example.
AV1025: For DTOs, a record is probably a better example
AV1026: Consider removing
New: Don't create a record with a constructor that takes more than 4 parameters. Use properties instead
New: When to use a record, and when to use a class
New: Consider a delegate instead of an interface with a single method
New: Use Primary constructors
Member Design Guidelines
AV1115: Consider removing as it is difficult to explain or validate
AV1125: Rewrite and start with the example of HttpContext.Current
AV1130: Revisit, as IEnumerable is often perceived as lazy-evaluated. And why not just return an array?
AV1137: Rewrite as "Keep parameters as specific and narrow as possible"
AV1140: Rewrite as "Consider created domain-specific types rather than primitives"
New: Use extension blocks
New: Avoid local functions
New: Use the field keyword
Miscellaneous Design Guidelines
AV1220: Remove as nobody uses events anymore
AV1250: Rename to "Materialize the result of a Iqueryable or Ienumerable expression before returning it"
Maintainability Guidelines
AV1500: Increase to 15
New: Align projects with the depllyment units, not layers
Remove: AV1510
AV1521: Remove the reference to Visual Basic and C
AV1523
Extend with array initializers, including spread operator
Remove the old example
AV1525: Remove as it is not something I see a lot
AV1530: Extend with foreach as well
AV1532: Remove, as LINQ statements are not always clearer. Use the right tool at the right time
AV1545
Take into considering the ? operator (conditional assignment and conditional expressions)
Also see if we can keep that section shorter
AV1546: Do some investigation on what string mechanism is the fastest in .NET 8 and later
AV1551: Consider removing it as it is not something I see a lot
AV1553: Check if this still makes sense and rewrite it to be shorter
AV1554: Still applicable?
AV1568: Remove. It's valid, but I don't see this a lot.
AV1580: Remove, as all debuggers support showing the individual sections
New: Considering duplicating code across different modules to reduce coupling
New: Use raw string literals
New: Make properties required
Testability Guidelines (1600)
Use short concise functional names
Show what's important, hide what's not
Avoid private helper methods to build various test objects
Use test Data Builders to build flexi
Exception: Sometimes a simple object mother is sufficent
Test behavior, not implementation details
Prefer inline literals over constant variables
Don't use production code in assertions
Use short fact-based test names
Postfix test classes with Specs instead of Tests
Test things designed to be reusable separately
Test implementations as part of a bigger scope
Naming Guidelines
AV1701: Remove the reference to other programming languages
AV1706: Mention the naming for abbreviations longer than 2 characters
AV1708: Not all code elements are rendered in code style
AV1737: Merge into AV1735
AV1738: Merge into AV1702
AV1755: Change so to only use Async when there are synchronous and asynchronous versions of a method
Add: Specs as postfix for tests
Performance Guidelines
AV1800: Shorten the text. Also look at what Roslyn analyzers are suggesting
AV1820: Emphasis the I/O aspect in the title
AV1825: Check if this is still the recommended approach
AV1835: Is this still relevant?
AV1840: Is this still true?
Framework Guidelines
AV2201: Is this still useful
AV2202: Revisist the examples
AV2207: Too .NET specific
AV2221: Verify this is still the best advice
AV2230: Shorten this
AV2235: Remove as it’s a bit stupid
New: Use "is null" instead of "== null"
New: Destructors and destructering tuples
New: Destructering arrays
Documentation Guidelines
AV2305: Add remark that isn't necessary
AV2307: Remove
New: Document what a member tries to do, not what it does or how it does it
New: Use REFACTOR and SMELL to track opportunities
Layout
Remove: "Start the LINQ statement with all the from expressions and don’t interweave them with restrictions."
Other
Mention Polysharp to use newer versions in C# 14
When to use extension properties
Null-conditional assignement
Collection expressions
ToDO
Review linsk & articles
Include an .editorconfig
Make the following changes on the
developbranchGeneral
Update version numbers to C# 14
Update cheat sheet
Introduction
Add something about the use of AI. E.g. using is fine, as long as you treat all that code as your own
Replace ".NET Framework" with just .NET
Mention my .NET Starter Kit as a good companion
Mention that this guideline is also used by all my open-source projects
Explain to apply DRY within boundaries, but duplicate code across boundaries when it's simple
Add the most critical coding guidelines on your PR template
Check all links to see if they point to valid files
Rider has a file structure window as well
Mention all my open-source projects and how they influenced the guidelines
Remove Gitter reference
Update social media links
Mention the many Roslyn analyzers and how directory.props can be used
General Guidelines
New: Understand the boundaries of your code base
New: Use design patterns to refactor code into a structure people can recognize by name
New: Prefer compoisiton over inheritance
Class Design Guidelines: Rename to "Type Design Guidelines" or "Class/Record Design Guidelines"
AV1000
Tip: If you can't find a good name for a class, or struggle to document, it's doing to much.
Tip: If you explain what the class does to an AI, it may help detect multiple responsibilities
For primitive types, consider an immutable record type
AV1001?: Only pass things to a constructor that most or all members need
AV1003: Avoid taking the name of the class and slapping an I in front of it
Consider using role-based names like IFetchSomething or IProvideClusterwideLock
AV1004: Typo in "a(n abstract)"
AV1005: Understand the boundaries of your code base. Use interfaces across boundaries, but avoid them within the boundary
AV1013: Rephrase as "Don't cast a base class to one of its derived classes". Also add an example.
AV1025: For DTOs, a record is probably a better example
AV1026: Consider removing
New: Don't create a record with a constructor that takes more than 4 parameters. Use properties instead
New: When to use a record, and when to use a class
New: Consider a delegate instead of an interface with a single method
New: Use Primary constructors
Member Design Guidelines
AV1115: Consider removing as it is difficult to explain or validate
AV1125: Rewrite and start with the example of HttpContext.Current
AV1130: Revisit, as IEnumerable is often perceived as lazy-evaluated. And why not just return an array?
AV1137: Rewrite as "Keep parameters as specific and narrow as possible"
AV1140: Rewrite as "Consider created domain-specific types rather than primitives"
New: Use extension blocks
New: Avoid local functions
New: Use the field keyword
Miscellaneous Design Guidelines
AV1220: Remove as nobody uses events anymore
AV1250: Rename to "Materialize the result of a Iqueryable or Ienumerable expression before returning it"
Maintainability Guidelines
AV1500: Increase to 15
New: Align projects with the depllyment units, not layers
Remove: AV1510
AV1521: Remove the reference to Visual Basic and C
AV1523
Extend with array initializers, including spread operator
Remove the old example
AV1525: Remove as it is not something I see a lot
AV1530: Extend with foreach as well
AV1532: Remove, as LINQ statements are not always clearer. Use the right tool at the right time
AV1545
Take into considering the ? operator (conditional assignment and conditional expressions)
Also see if we can keep that section shorter
AV1546: Do some investigation on what string mechanism is the fastest in .NET 8 and later
AV1551: Consider removing it as it is not something I see a lot
AV1553: Check if this still makes sense and rewrite it to be shorter
AV1554: Still applicable?
AV1568: Remove. It's valid, but I don't see this a lot.
AV1580: Remove, as all debuggers support showing the individual sections
New: Considering duplicating code across different modules to reduce coupling
New: Use raw string literals
New: Make properties required
Testability Guidelines (1600)
Use short concise functional names
Show what's important, hide what's not
Avoid private helper methods to build various test objects
Use test Data Builders to build flexi
Exception: Sometimes a simple object mother is sufficent
Test behavior, not implementation details
Prefer inline literals over constant variables
Don't use production code in assertions
Use short fact-based test names
Postfix test classes with Specs instead of Tests
Test things designed to be reusable separately
Test implementations as part of a bigger scope
Naming Guidelines
AV1701: Remove the reference to other programming languages
AV1706: Mention the naming for abbreviations longer than 2 characters
AV1708: Not all code elements are rendered in code style
AV1737: Merge into AV1735
AV1738: Merge into AV1702
AV1755: Change so to only use Async when there are synchronous and asynchronous versions of a method
Add: Specs as postfix for tests
Performance Guidelines
AV1800: Shorten the text. Also look at what Roslyn analyzers are suggesting
AV1820: Emphasis the I/O aspect in the title
AV1825: Check if this is still the recommended approach
AV1835: Is this still relevant?
AV1840: Is this still true?
Framework Guidelines
AV2201: Is this still useful
AV2202: Revisist the examples
AV2207: Too .NET specific
AV2221: Verify this is still the best advice
AV2230: Shorten this
AV2235: Remove as it’s a bit stupid
New: Use "is null" instead of "== null"
New: Destructors and destructering tuples
New: Destructering arrays
Documentation Guidelines
AV2305: Add remark that isn't necessary
AV2307: Remove
New: Document what a member tries to do, not what it does or how it does it
New: Use REFACTOR and SMELL to track opportunities
Layout
Remove: "Start the LINQ statement with all the from expressions and don’t interweave them with restrictions."
Other
Mention Polysharp to use newer versions in C# 14
When to use extension properties
Null-conditional assignement
Collection expressions
ToDO
Review linsk & articles
Include an .editorconfig