Lines are what your editor shows; statements are what your program does. Every metric built on physical lines inherits formatting noise — and every decision built on that metric inherits it too.
One real 35-line source file, counted four ways: 35 physical lines · 25 source lines (blank lines and comments removed) · 6 logical statements · 5 statements of working code (executable logic, once declarations and data are set apart). Four numbers, one file — and they answer different questions. Team size and cost models want the first two. Anything about behaviour — what changed, what's at risk, what needs review — lives in the last two.
Take one ordinary commit: a reformat, a data-table refresh, and a single behavioural change. A line counter reports 12 lines of churn. The truth is one changed statement. The line-based number is not wrong — it's answering "how many lines moved?", which nobody actually asked. Statement-level counting is stable under formatting, brace style, and line-wrapping conventions, which is precisely why it can gate a merge or anchor an audit record without punishing a developer for running the formatter.
Statement-level change accounting wasn't invented for dashboards. It was first demanded by an avionics organisation whose line counter could not tell them what had actually changed between two builds of flight software. When the cost of not knowing is that high, "lines moved" stops being an acceptable answer.
CodeDelta counts logical statements across 43 languages — each language parsed as written, not approximated with regular expressions — and measures churn at that level: every statement added, deleted, or edited in place between any two versions. Every figure in the paper is real engine output you can reproduce by hand on the file it dissects. Count your own codebase both ways — the gap between the line number and the statement number is the noise you've been reporting.