Tirsvad
304ec7751b
New criteria, appended after the existing ones (nothing renumbered or changed): - DRY in all five qc-programming-* checklists (python, c, cpp, csharp, shell) - dependency rule in all but shell (imports, includes or references point inward, no cycles; in C also one responsibility per module) - SOLID in python, cpp and csharp - qc-dcd.md criterion 9: dependencies between classes and packages point inward (cycles stay with criterion 8) Each is tagged with an ISO/IEC 25010 characteristic, and the criterion Notes name the rule in the framework's coding-conventions skill, which defines it once. Each checklist has a new Proposed Version History row for S02, who accepts coding-standard changes. Common Defects gain a bullet per criterion.
67 lines
5.3 KiB
Markdown
67 lines
5.3 KiB
Markdown
# Quality Criteria: C# Source Code
|
|
|
|
## Metadata
|
|
| Key | Value |
|
|
| --- | --- |
|
|
| ID | QC-CS-001 |
|
|
| CrossReference | [QC-DCD-001], [QC-ADR-001] |
|
|
| DomainLanguages | IT Professional English |
|
|
|
|
## Version History
|
|
| Date | Status | Author | Reviewer | Change | Commit |
|
|
| --- | --- | --- | --- | --- | --- |
|
|
| 2026-10-01 | Accepted | Jens Tirsvad Nielsen | S07 | First public release (1.0.0) | — |
|
|
| 2026-10-09 | Proposed | Jens Tirsvad Nielsen | S02 | Added criteria 14 to 16 (DRY, dependency rule and SOLID) | pending |
|
|
|
|
---
|
|
|
|
## Purpose
|
|
|
|
C# code carries the design into a managed runtime where naming, nullability, disposal and async usage decide whether it stays maintainable and correct. This checklist confirms that C# code follows the C# coding conventions (Microsoft naming and design guidelines), so that it is consistent with .NET practice and with the design it implements.
|
|
|
|
## Quality Criteria Checklist
|
|
|
|
Level: **Mandatory** criteria are the baseline every instance must meet; **Optional** criteria are advanced and may be deferred.
|
|
|
|
| # | Criterion | Level | ISO/IEC 25010 Characteristic(s) | Notes |
|
|
| --- | --- | --- | --- | --- |
|
|
| 1 | Types, methods, properties and constants are `PascalCase`; parameters and locals `camelCase`; private fields `_camelCase`; interfaces start with `I` | Mandatory | Maintainability, Usability | |
|
|
| 2 | Async methods end in `Async`; exceptions end in `Exception`; one top-level type per file, named after the file | Mandatory | Maintainability, Usability | |
|
|
| 3 | Code is formatted per the project's `.editorconfig` and builds with no unexplained analyzer suppressions | Mandatory | Maintainability | |
|
|
| 4 | Nullable reference types are enabled; the null-forgiving operator (`!`) is justified in a comment | Mandatory | Reliability | |
|
|
| 5 | `IDisposable` objects are disposed with `using`; no resource leaks on exception paths | Mandatory | Reliability, Performance Efficiency | |
|
|
| 6 | Async code uses `await` throughout: no `.Result` or `.Wait()` and no `async void` outside event handlers | Mandatory | Reliability, Performance Efficiency | |
|
|
| 7 | Specific exceptions are thrown; arguments are validated at public boundaries; rethrow uses `throw;`; no empty `catch` | Mandatory | Reliability, Security | |
|
|
| 8 | Public types and members have XML documentation comments | Optional | Usability, Maintainability | |
|
|
| 9 | State is exposed through properties, not public fields; immutability (`readonly`, `init`, `record`) is preferred where it fits | Optional | Maintainability, Reliability | |
|
|
| 10 | Money uses `decimal`; points in time use `DateTimeOffset` | Mandatory | Functional Suitability, Reliability | |
|
|
| 11 | Public async APIs accept and pass a `CancellationToken` where the operation can be cancelled | Optional | Performance Efficiency, Reliability | |
|
|
| 12 | Tests cover new behaviour, are named `Method_Condition_Expected`, and do not depend on order, time or the network | Mandatory | Reliability, Maintainability | |
|
|
| 13 | Classes and members trace to the Design Class Diagram they implement; deviations are recorded | Mandatory | Functional Suitability, Maintainability | |
|
|
| 14 | Each piece of knowledge (a business rule, constant, format, validation or query) is defined in one place; code is merged only where it expresses the same knowledge, not where it merely looks alike | Mandatory | Maintainability | Modularity, Reusability. Rule: `coding-conventions` skill, “State each piece of knowledge once” |
|
|
| 15 | Namespace and project references point inward: business-rule code references no framework, database, UI or delivery-mechanism code, and there are no reference cycles | Mandatory | Maintainability, Portability | Modularity, Portability. Rule: `coding-conventions` skill, “Dependencies point inward” |
|
|
| 16 | SOLID holds: a class has one reason to change; new behaviour is added by extension, not by editing a type test in several places; subtypes honour the contract of their base; interfaces are narrow; high-level code depends on interfaces and receives its implementations by injection | Mandatory | Maintainability | Single responsibility is the most commonly violated. Rule: `coding-conventions` skill, “SOLID” |
|
|
|
|
## Common Defects
|
|
|
|
- camelCase methods or snake_case members carried over from another language
|
|
- Nullable warnings silenced with `!` or pragmas
|
|
- `Task.Result` or `.Wait()` on the request path (deadlocks and thread starvation)
|
|
- `throw ex;` destroying the stack trace; empty `catch` blocks
|
|
- Undisposed `HttpClient`, streams or database connections
|
|
- `DateTime` used for instants, or `double` for money
|
|
- Several public types in one file, or a file name that differs from its type
|
|
- The same rule, constant or validation written in two places, or two methods merged because they look alike although they change for different reasons
|
|
- Business-rule code that references the ORM, the web framework or a database driver
|
|
- A class with several unrelated responsibilities, or `is`/`switch` type tests repeated in several places
|
|
|
|
## Traceability Rule
|
|
|
|
- Backward: Design Class Diagram checklist ([QC-DCD-001]) for the classes and members being implemented; Architecture Decision Record checklist ([QC-ADR-001]) for the decisions that constrain the implementation
|
|
- Forward: none — source code is the end of the QC checklist chain
|
|
|
|
---
|
|
|
|
[QC-DCD-001]: ./qc-dcd.md
|
|
[QC-ADR-001]: ./qc-adr.md
|