TirSystem/sqa-qc-checklists
2
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Add DRY, dependency and SOLID criteria to the code checklists (MIL-009 task 5)

Browse Source 
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.
This commit is contained in:
Tirsvad
2026-10-09 11:26:58 +08:00
parent 02b520b570
commit 304ec7751b
6 changed files with 33 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qc-programming-python.md
+7
View File
@@ -11,6 +11,7 @@
| 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 |
---
@@ -37,6 +38,9 @@ Level: **Mandatory** criteria are the baseline every instance must meet; **Optio
| 11 | Tests exist for new behaviour, are named for the behaviour, and do not depend on order or the network | Mandatory | Reliability, Maintainability | |
| 12 | Type checker runs in strict mode without errors; `Any` is justified in a comment | Optional | Reliability, Maintainability | |
| 13 | Dependencies are declared and pinned in the project's dependency file, none unused | Optional | Portability, Security | |
| 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 | Imports point inward: business-rule modules import no framework, database, UI or delivery-mechanism code, and there are no import cycles | Mandatory | Maintainability, Portability | Modularity, Portability. Rule: `coding-conventions` skill, “Dependencies point inward” |
| 16 | SOLID holds: a class or module has one reason to change; new behaviour is added by extension, not by editing a type test in several places; subclasses honour the contract of their base; protocols are narrow; high-level code depends on protocols or abstract types and receives its implementations | Mandatory | Maintainability | Single responsibility is the most commonly violated. Rule: `coding-conventions` skill, “SOLID” |
## Common Defects
@@ -47,6 +51,9 @@ Level: **Mandatory** criteria are the baseline every instance must meet; **Optio
- `print` used for diagnostics; wildcard imports
- Code reformatted by hand, or an unrelated reformat mixed into a functional change
- Classes or methods that appear in no design artifact and have no stated reason
- The same rule, constant or validation written in two modules, or two functions merged because they look alike although they change for different reasons
- Business-rule modules importing the ORM, the web framework or a database driver
- A class with several unrelated responsibilities, or an `isinstance` chain repeated in several places
## Traceability Rule