clines vs cloc
cloc has counted lines of code since 2006 and is the reference implementation for the job. Any tool claiming to replace it should first demonstrate it agrees with it. So that is where this comparison starts, before getting to what is different.
Do they agree?
Both tools were run over an identical file set — clines produced the list of 6,914 files,
which was then handed to cloc with --list-file, so neither tool chose its own
input. --skip-uniqueness was passed to cloc because it de-duplicates
identical files by default and clines does not.
| clines | cloc | difference | |
|---|---|---|---|
| Code lines | 823,300 | 822,301 | +0.12% |
| Blank lines | 103,919 | 103,898 | +0.02% |
| Comment lines | 81,280 | 81,960 | −0.83% |
The residual is not noise. JavaScript blank counts are identical at 64,438, and the code and comment figures differ by exactly 548 in opposite directions — a set of lines one tool reads as code and the other as comment, not lines that went missing. Rust differs by exactly one line, in the same trade. HTML, CSS, YAML, CoffeeScript, TOML and JSX match cell for cell.
On a small hand-checked fixture, with block comments, a keyword-bearing string and a trailing comment, the two tools agree on every value.
cloc classified 6,895 of the 6,914 files and skipped 19 it did not recognise, which is
part of the code difference. clines folds unknown extensions into an Other
bucket rather than dropping them.
Reproducing it
clines count . --all
cloc --skip-uniqueness .
The --all matters. Since 4.0.0 clines reports on source files only, excluding
tests, fixtures, generated and vendored code, so a like-for-like comparison with cloc
needs it. Without it clines reports 2,022 files rather than 6,914 — a difference of
intent, not of counting.
Run that way each tool picks its own input and the totals will differ a little, because
each has its own ignore rules. The figures above were produced by handing cloc clines'
exact file list through --list-file, so the only remaining variable was how
each tool classifies a line. That needed a short script against clines'
collectFiles, because there is no flag to print the file list — a reasonable
thing to add, and not something the tool does today.
Where cloc is the better choice
-
Language coverage. cloc knows hundreds of languages. clines knows the common ones
and folds the rest into an
Otherbucket. - Maturity. Fifteen years of edge cases, from Perl POD to Visual Basic forms.
- Output formats. XML, YAML, SQL, CSV. clines prints a table or writes HTML.
-
Diffing.
cloc --diffcompares two trees. clines has no equivalent.
If you want to count lines of code across an unusual language set, use cloc. It is better at that, and clines does not try to beat it.
What clines adds
Counting is the starting point rather than the product. The other five commands answer questions cloc does not attempt:
| command | question |
|---|---|
dup |
Which code is duplicated, and where are the copies? |
cx |
Which files carry the most decision points? |
ctx |
What does this repository cost a language model to read? |
comments |
Which comments has the code drifted away from? |
refactor |
Which files are worth refactoring, and what has re-reading them cost? |
There is also a difference in default. cloc counts what you point it at. Since 4.0.0 clines classifies every file as source, test, generated, vendored or documentation and reports on source alone, because on react the other categories accounted for 59% of the estimated token cost and 72% of all duplicated lines. Both defaults are defensible; they answer different questions.
Which to use
- Counting lines, many languages, scripting against the output: cloc.
- Understanding a codebase you are about to work in — duplication, complexity, what it costs an agent to read: clines.
- Both: they do not conflict, and now you know the counts agree.
npm install --save-dev clines