- Description
- Test tubes
- Source
- B.Lachner · original page
- Licence
- CC0 Public domain
Code Quality
This theme measures code readability and reliability at the moment it is modified: defects caught before merge, conventions applied without debate, reviews that teach as much as they…
In brief
This theme measures code readability and reliability at the moment it is modified: defects caught before merge, conventions applied without debate, reviews that teach as much as they control. It does not measure the “number of rules” but the rate of defects that slip through and the time to review a change.
Level: 🟢→🔴 · Theme code: COD (DL matrix)
Why this theme#
Code is read far more often than it is written. Unreadable code is not just unpleasant: it multiplies correction time, drives reviewers away (reviews become rubber-stamp approvals), and lets defects pass that tools would catch for free. Conversely, too many cosmetic rules create noise: if static analysis reports 3,000 warnings, no one reads a single one anymore.
In SQL and automation scripts, the pitfall is specific: single-block 600-line queries, implicit joins, SELECT *, silent type conversions, PowerShell scripts without error handling. The same principles apply, with different tools (T-SQL analysis, PSScriptAnalyzer).
What this theme measures#
- Axis: from “everyone has their own style” to “quality is a property verified with every change”.
- Key indicator: escape rate (share of code defects discovered after merge); median merge request age (from open to merge).
- Unit: % of escaped defects; review latency hours; debt reported by static analysis per thousand lines.
Five-level table#
| Level | Short name | Promise | Typical indicator (order of magnitude) |
|---|---|---|---|
| 1 | Individual | The code works; quality depends on the person who writes it. | No shared control; exceptional review |
| 2 | Agreed | A colleague's code is readable using the same conventions as yours. | Style guide; review on > 50% of changes |
| 3 | Verified | A common defect is flagged even before someone reviews. | Static analysis in CI; review latency < 1 business day |
| 4 | Controlled | The quality of a change is measured and compared over time; new code never degrades existing code. | “Clean as you code”: 0 new blocking defect; escape rate < 10% |
| 5 | Exemplary | Code is fixed and refactored without fear or coordination; quality attracts contributions. | Escape rate < 3%; measured continuous refactoring |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| DL-COD-1.1 | Code compiles/runs from a versioned source | Rebuild from a fresh clone |
| DL-COD-1.2 | Variable names, SQL objects, and scripts follow a shared minimum convention | Review of a sample of 20 objects |
| DL-COD-1.3 | Known errors are logged, not swallowed | No empty catch or silent ON ERROR in the sample |
| DL-COD-2.1 | A style guide (naming, schema, indentation) is written and accessible | Dated document < 12 months |
| DL-COD-2.2 | Every modification goes through third-party review before merge | ≥ 90% of merged changes have a reviewer |
| DL-COD-2.3 | A review checklist exists (security, errors, naming) | Checklist present in the request template |
| DL-COD-2.4 | Formats (indentation, end-of-line, encoding) are set in a configuration file | Versioned configuration |
| DL-COD-3.1 | An automatic formatter is applied pre-commit or in CI | A style drift causes CI to fail |
| DL-COD-3.2 | Static analysis (linter, T-SQL analysis, PSScriptAnalyzer) runs on every merge request | Report attached to every PR |
| DL-COD-3.3 | Median review latency is < 1 business day | Measurement over 3 months |
| DL-COD-3.4 | Secrets, passwords, or connection strings are detected before merge | Active detector, deliberate test detected |
| DL-COD-4.1 | Quality thresholds apply to new code (complexity, duplication, coverage) and block merge | A deliberate over-threshold case is rejected |
| DL-COD-4.2 | The escaped defect rate is measured and tracked quarterly | Trend over 4 quarters |
| DL-COD-4.3 | Reviews are size-bounded (≈ ≤ 400 modified lines) | PR size distribution |
| DL-COD-4.4 | Recurring review decisions become automated rules | List of rules derived from reviews |
| DL-COD-5.1 | Core cyclomatic complexity and coupling decrease or remain stable over 12 months | 12-month curve |
| DL-COD-5.2 | Refactoring is routine, protected by tests, with no “dedicated project” | ≥ 1 tracked refactoring per iteration |
| DL-COD-5.3 | A new contributor gets a useful review in under 4 hours | First-response measurement |
| DL-COD-5.4 | Exemplary code is identified and used as a reference (templates, examples) | Template repository used in practice |
Detailed reading by level#
🟢 Level 1 — Individual#
- Signs: three styles in the same repository; 500-line scripts without functions; ignored errors.
- Gain: writing speed on a scope touched by only one person.
- Does not guarantee: that a third party can take over; that a defect is seen before production.
- Difficulty: 1/5 · Effort: 1/5.
🟢 Level 2 — Agreed#
- Signs: style guide, third-party review, review checklist. Style debates stop taking up review time.
- Gain: part of the defects are detected by a second set of eyes; knowledge circulates.
- Does not guarantee: consistency — review depends on human attention and degrades under pressure.
- Difficulty: 2/5 · Effort: 2/5.
🟡 Level 3 — Verified#
- Signs: the machine does what is mechanical (formatting, secret detection, static analysis), humans review substance. Review time decreases.
- Gain: fewer trivial defects; reviews focused on design.
- Does not guarantee: design quality, nor control of existing code.
- Difficulty: 3/5 · Effort: 3/5.
🔴 Level 4 — Controlled#
- Signs: the bar applies to new code (“clean as you go”), which avoids the “clean everything first” trap. Escaped defects are analyzed to improve rules and tests.
- Gain: existing code stops degrading without blocking delivery.
- Does not guarantee: functional correctness — see 03 Testing.
- Difficulty: 4/5 · Effort: 4/5.
🔴 Level 5 — Exemplary#
- Signs: refactoring is daily and secured by tests; code serves as documentation; contributions from outside the team are easy.
- Gain: the ability to change quickly without breaking, sustainably.
- Does not guarantee: absence of debt — design debt remains (09).
- Difficulty: 5/5 · Effort: 4/5.
Partial achievement and rating#
Apply the rating rule. Reference points:
- 0.5 on DL-COD-3.2: static analysis runs but only on one of the two repositories (e.g., C# but not SQL scripts).
- 0.5 on DL-COD-4.1: thresholds active on new code but non-blocking.
- A partial 5: routine refactoring and fast review, but no 12-month trend measurement yet.
Ignored warnings. Symptom: thousands of alerts, never read. Cause: no threshold, unsorted rules. Remedy: disable what is not actionable, block on new code only.
Move to the next level#
Possible means (optional) — the target result remains the one in the promise.
- 1 → 2: one conventions file (one page) and the rule “no one merges alone.”
- 2 → 3: formatter and linter in CI, secret detector, size-limited review.
- 3 → 4: thresholds on new code, escaped defect analysis, rules derived from reviews.
- 4 → 5: refactoring budget in each iteration, characterization tests on existing code.
A 150-line merge request is reviewed in 15 minutes; a 1,500-line one is approved “without looking.” Bound size, not duration.
A “zero alerts” target pushes teams to remove rules. A coverage target pushes shallow tests. Track trend and escape rate, never an isolated threshold.
Code assistants speed up writing and suggest first-level reviews (gain 4/5, risk 3/5: plausible but wrong code, invented dependencies). Safeguard: CI applies the same gates to generated code as to human code; responsibility remains with the reviewer.
A 900-line SQL consolidation script is split into three procedures named by role. Static analysis flags two SELECT * and one implicit conversion; review focuses only on join logic.
See also#
- Neighbors: 01 Architecture · 03 Testing · 05 CI · 09 Technical Debt · 12 Developer Experience.
- Other matrices: BI — DAX Measures and Calculations · Project — Quality and UAT (QUA) · Data — Data Quality.
- Practice: CI/CD: Continuous Integration and Continuous Delivery · Git in Depth · Azure DevOps / TFS · Pitfalls and good practices in project management (cross-functional summary).
- Glossary · Rating: Reading Ratings, Scores, and the Legend.
✻ Written by Claude Sonnet 5.5
