Code Quality Metrics

A quantitative measure of the number of linearly independent paths through a piece of code. Calculated as edges − nodes + 2 × connected components in the control flow graph. Values above 10 are typically considered complex.

"The user authentication method has a cyclomatic complexity of 27 — 27 linearly independent paths through the code. SonarQube flags anything above 15 for our project. This needs to be refactored into smaller methods."

A code complexity metric designed to measure how hard code is for a human to understand, rather than how many paths exist. It penalises nesting depth, recursion, and control flow jumps more than cyclomatic complexity.

"The cognitive complexity score of 45 is more telling than the cyclomatic complexity of 22 — the 5-level nesting of conditionals inside a loop makes this function genuinely hard to reason about, even for the original author."

The frequency with which lines of code are modified over a time period. High churn in a file indicates either ongoing active development or instability — when combined with high complexity, it identifies code quality hotspots.

"CodeScene identified the OrderService class as the top hotspot: cyclomatic complexity 64, code churn 340 modifications in 12 months. This single class accounted for 58% of production bugs in the same period."

In code quality tools, technical debt is expressed as the estimated remediation time to bring code to a defined quality standard. SonarQube calculates it per violation based on the SQALE method.

"SonarQube calculated 28 days of technical debt in the core module — 18 days from duplicated code, 6 days from complexity violations, 4 days from missing unit tests. The tech debt ratio is 31%."

The percentage of production code executed by automated tests. Typically measured as line coverage, branch coverage, or both. A common baseline is 80% line coverage, but coverage should be read alongside mutation score.

"Test coverage is 67% overall, but the payment module — our highest-risk code path — is only at 34%. We have 100% coverage of utility functions that almost never change and almost none of the code that actually handles money."

Four key engineering performance indicators from the DevOps Research and Assessment programme: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. Elite performers deploy multiple times per day with MTTR under one hour.

"Our current DORA metrics: Deployment Frequency: twice per week (Medium). Lead Time: 3 days (Medium). MTTR: 4 hours (Medium). Change Failure Rate: 8% (Low). The team goal is Elite on all four by Q4."

A DORA metric measuring the percentage of deployments that cause a production incident requiring a hotfix, rollback, or patch. Elite teams achieve below 5%; high rates indicate insufficient testing or risky deployment practices.

"Change failure rate spiked to 22% in Q2 — 1 in 5 deployments triggered a production incident. Root-cause analysis showed 80% of failures were missing integration tests for third-party API responses. Mandatory integration test coverage for external callouts was added to the Definition of Done."

Automated code review performed without executing the code — checking for security vulnerabilities, style violations, complexity thresholds, dead code, and common bug patterns. Tools include SonarQube, ESLint, Checkstyle, and Semgrep.

"Static analysis in CI blocks merges if: any Critical severity security violation is introduced, cognitive complexity exceeds 25, or test coverage on modified files drops below 80%. These gates run in under 2 minutes on every PR."

The most widely used static analysis platform in enterprise software development. Analyses codebases for bugs, vulnerabilities, and code smells, tracks technical debt, calculates quality gate pass/fail status, and shows trends over time.

"The SonarQube quality gate failed on the PR: 3 new Blocker-severity security hotspots (SQL injection risk), tech debt delta +2 days, and coverage on new code at 61% against our 80% threshold. The merge is blocked until these are resolved."

A set of conditions that new code must meet before it can be merged or deployed. Typically checks new-code coverage, new critical violations, and tech debt delta. Fails the CI pipeline if conditions are not met.

"Our quality gate has 4 conditions: (1) new code coverage ≥ 80%, (2) zero new Blocker/Critical bugs, (3) zero new security vulnerabilities, (4) no new code smells rated Major or above. The gate auto-fails the CI pipeline on violation."

A testing technique that evaluates test quality by making small code changes (mutations) and checking whether tests detect them. A mutation score above 80% indicates tests actually verify behaviour; high line coverage with low mutation score indicates superficial tests.

"Line coverage is 85% but mutation score is only 34% — most tests call the code without asserting the output. Mutation testing revealed we have quantity of tests, not quality. We need assert-driven refactoring of the test suite."

An international standard for software product quality, defining 8 quality characteristics (functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, portability) each with sub-characteristics.

"The architecture assessment used ISO 25010 as the evaluation framework. The weakest dimension was Reliability — specifically fault tolerance (no circuit breakers) and recoverability (no automated failover). The strongest was Security (maintainability was Amber due to low test coverage)."