📐 Code Quality & Engineering Metrics Language

Cyclomatic complexity is a software metric that measures the number of independent paths through a piece of code — typically a function or method. It is calculated by counting decision points (if statements, loops, switch cases) plus one. A cyclomatic complexity above 10 is often cited as a threshold requiring refactoring. Engineers use phrases like "this function has a cyclomatic complexity of 15 — it needs to be split," or "high cyclomatic complexity correlates with higher defect rates and lower testability."

Code coverage measures the percentage of source code lines, branches, or paths exercised by a test suite. Line coverage is the most common metric; branch coverage tracks whether both true and false outcomes of every conditional are tested. Engineers discuss coverage as a quality gate — "we require 80% branch coverage before merging to main" — while also acknowledging its limits: high coverage does not guarantee meaningful tests or absence of defects.

DORA metrics are four key measures of software delivery performance derived from research by the DevOps Research and Assessment team: deployment frequency (how often code is released to production), lead time for changes (time from commit to production), change failure rate (percentage of deployments causing incidents), and mean time to restore (MTTR — how quickly service is recovered after an incident). Elite engineering teams use these metrics to benchmark performance and communicate progress to engineering leadership.

Technical debt ratio is a metric from SonarQube that expresses the ratio of the estimated time to fix all code issues to the estimated time to build the application from scratch, expressed as a percentage. A ratio below 5% is considered "A" grade (maintainable). The metric gives product and engineering leadership a single number to represent codebase health. Engineers use phrases like "our technical debt ratio has increased from 3% to 8% this quarter" in quality reporting conversations.

A code smell is a surface indicator in source code that may suggest a deeper structural problem — not a bug, but a pattern that makes the code harder to maintain, extend, or understand. Common code smells include long methods, duplicate code, excessive parameters, feature envy, and God classes. In professional English, engineers say "this class exhibits feature envy — it accesses data from another object more than its own" or "we have significant duplication here that's a code smell worth addressing in the next refactoring sprint."

The maintainability index is a composite metric calculated from Halstead volume, cyclomatic complexity, and lines of code, producing a score typically between 0 and 100. Higher scores indicate more maintainable code. Microsoft Visual Studio uses a threshold of 10–19 as "difficult to maintain" and 0–9 as "unmaintainable." Teams use this metric in code quality dashboards to identify modules requiring urgent attention, and engineers discuss it with phrases like "the maintainability index on this module dropped below 20 after the last sprint."

Mutation testing is a technique that introduces small, deliberate changes — called mutations — to source code (for example, changing a + to a - or a true to a false) and checks whether the existing test suite catches them. If a mutation "survives" (the tests still pass), it reveals a gap in test coverage quality, not just quantity. Engineers use mutation testing to distinguish a high-coverage test suite that actually validates behaviour from one that merely executes code without meaningful assertions.

Deployment frequency is one of the four DORA metrics and a proxy for engineering team agility and process health. Elite teams deploy to production multiple times per day; high-performing teams deploy between once per day and once per week. In performance reviews and retrospectives, engineers frame it as: "our deployment frequency has increased from weekly to daily since we automated our QA pipeline — this reduces the batch size of each release and lowers our change failure rate." It is both a throughput and risk management metric.

Cognitive complexity, introduced by SonarSource, measures how difficult a piece of code is for a human to understand, rather than just counting paths. It penalises deeply nested structures and increments for structural breaks like recursion and logical operators within conditions. While cyclomatic complexity penalises each decision point equally, cognitive complexity penalises nesting more heavily — so a deeply nested if-else scores higher than the same logic written as a flat chain. It is increasingly preferred for readability-focused quality discussions.

CoderLingo's Code Quality and Engineering Metrics Language section includes five exercise sets: code complexity metrics vocabulary (cyclomatic complexity, Halstead metrics, maintainability index), code coverage and quality gates (branch coverage, mutation testing), DORA metrics communication, software quality attributes based on ISO 25010, and technical debt measurement language using SonarQube vocabulary. Sets range from Intermediate to Advanced level.