Lines of Code (LOC) as a Metric
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). Tools listed — phploc, phpmetrics, sonarqube, cloc — are specialist static analysis and metrics tools, not default linters. They can flag files >500 lines or methods >50 lines automatically, but a developer must deliberately run or configure them; misuse of LOC as a sole metric won't be caught by a compiler or standard linter.
Closest to 'simple parameterised fix' (e3). The quick_fix states LOC should be used as a starting indicator alongside cyclomatic complexity, cohesion, and test coverage. Correcting the misuse means adjusting metric dashboards and team practices — a small but non-trivial change — rather than a single-line code patch. It touches team conventions and tooling config rather than a broad codebase refactor.
Closest to 'localised tax' (b3). LOC as a metric applies across web, cli, and queue-worker contexts, but its burden is primarily on the team's measurement and review practices rather than the production codebase itself. Misusing it as a productivity proxy distorts incentives but doesn't structurally infect architecture the way a shared abstraction would; the damage is contained to process and review workflows.
Closest to 'serious trap' (t7). The misconception field explicitly states 'fewer lines of code always means better code' — a belief that contradicts how experienced developers know compact code can be less maintainable. The common_mistakes reinforce this: LOC is routinely misused as a productivity metric, as the only size metric, and triggers gaming behaviour (compressing statements, bloating lines). This contradicts reasonable developer intuition and mirrors how similar-sounding 'quality metrics' behave in other domains, making it a serious cognitive trap.
Also Known As
TL;DR
Explanation
Lines of Code has three variants: physical LOC (all lines), source LOC (non-blank, non-comment), and logical LOC (statements). LOC is useful for normalising defect density (defects per KLOC) and tracking codebase growth trends. As a standalone quality metric it is misleading — a 500-line function and ten 50-line functions share the same LOC but differ enormously in maintainability. LOC is best used alongside complexity metrics (cyclomatic, cognitive) rather than as a target. Setting LOC limits per file in CI is a lightweight smell detector that flags candidates for refactoring review.
Common Misconception
Why It Matters
Common Mistakes
- Treating LoC as a productivity metric — incentivising more lines produces bloated, verbose code.
- Using LoC as the only size metric — a 50-line function with 15 branches is more problematic than a 200-line class with simple sequential logic.
- Reducing LoC by compressing multiple statements onto one line — not an improvement.
- Not normalising LoC by language — PHP and Java will naturally produce different counts for equivalent logic.
Code Examples
// 'Reducing' LoC by unreadable compression — worse, not better:
function p($u){return$u->a&&$u->v&&!$u->b?'active':($u->b?'banned':'inactive');}
// Low line count, zero readability — meaningful LoC reduction requires refactoring, not compression// Lines of Code (LOC) is a simple but blunt metric
// Logical LOC (non-blank, non-comment) is more meaningful
// Tools to measure PHP LOC:
$ phploc src/
// Reports: LOC, LLOC (logical), CLOC (comment), NCLOC, methods, classes
// Rough guidelines (not strict rules):
// Method: < 20 LLOC
// Class: < 200 LLOC
// File: < 400 LLOC
// LOC alone doesn't indicate quality — pair with:
// - Cyclomatic complexity
// - Test coverage
// - Maintainability Index
// SonarQube and PHPMetrics produce LOC dashboards:
$ phpmetrics --report-html=report/ src/