scc test: 2085 files counted in 1225 ms

scc is a source code counter. It walks a directory, classifies files by language, and prints one row per language with file count, total lines, blanks, comments, code lines and a complexity score.

The problem it solves is that line counts lie unless the tool separates code from comments and blanks. A project with 58169 total lines can hold fewer than 47000 lines of actual PHP, and the difference matters when you are estimating work.

I ran it over a 42354495-byte working directory to see two things: how long a scan of that size takes, and which numbers in the output are trustworthy.

A single 18639360-byte executable

The release zip is 7244303 bytes and expands to three files: the binary, a README and a license. Nothing to install.

Language definitions ship inside the binary

# Three runs: 194 / 152 / 145 ms
scc --version
scc version 4.1.0

18639360 bytes is large for a counter because the language table is compiled in. It recognises 200-plus languages without a config directory, which is also why there is nothing to keep in sync after an upgrade.

145 ms to start, 1.2 seconds to scan

Printing a version number is not the same as doing work. The scan below took 1225 ms on the median against 145 ms of launch cost, so roughly nine tenths of the wall time is reading files.

2085 files, 360159 lines, 1225 ms

The target directory holds PHP, Python, JSON, HTML and a pile of generated XML. Three runs took 1529, 1225 and 1334 ms.

Output is 27 lines regardless of file count

2085 files collapse into 15 language rows plus totals, borders and the estimate block. That is the point of the tool: one screen instead of a per-file listing.

Bytes processed comes from scc itself

The last line of the output says Processed 42,354,495 bytes, 42.354 megabytes (SI). That figure is internal, so you can compare it against the folder size to confirm nothing was skipped.

The line count is dominated by 10 files

XML accounts for 10 files and 187372 lines out of 360159 total. That is 52 percent of every line counted, from 0.5 percent of the files.

Generated files inflate the total

Those XML files are data dumps, not source. Counting them pushes the total to 360159 lines while the hand-written PHP and Python together are 77359 lines. Any per-line estimate built on the total will be wrong by a factor of four.

Exclude before you quote a number

scc has --exclude-dir and ignore-file support for exactly this. Running once to see the language split, then again with exclusions, is the honest sequence.

# First pass: see what dominates
scc D:\project
# Second pass: drop generated data
scc --exclude-dir vendor,build D:\project

Blanks, comments and complexity

The totals row separates 360159 lines into 22027 blanks, 9679 comments and 328453 code lines. That split is the reason to use this tool instead of counting newline characters.

Complexity is per language, not per project

PHP carries 6390 of the 15638 total complexity points across 58169 lines, while JavaScript carries 5359 across only 2411 lines. Per line, the JavaScript is far denser, which is what a complexity column is for.

Data formats score zero

JSON, XML, CSV and SVG all report 0 complexity, because there is no branching to count. Seeing a zero is a useful signal that the row is data rather than logic, and it is why the 187372 XML lines do not move the complexity total at all.

The cost estimate is the odd feature

Below the table, scc prints a COCOMO-style estimate: Estimated Cost to Develop (organic) $11,856,008, Estimated Schedule Effort (organic) 35.20 months, Estimated People Required (organic) 29.92.

It is a formula, not a measurement

The numbers come from the basic COCOMO model applied to the line count. Feed it 187372 lines of generated XML and it will happily price them as hand-written work, which is how a small directory becomes an eight-figure project.

Useful only after exclusion

With generated data removed, the same formula becomes a rough sanity check on effort. Treat it as a conversation starter, never as a budget.

Before you run it

Nothing to install and nothing written to disk. The two things that change the answer are what you include and which languages it recognises.

Unknown extensions are skipped silently

A file with an extension not in the table is not counted and does not appear as an error. If a total looks short, add the language with --include-ext or check the file is not ignored.

Small directories give small numbers

A second directory of 802 bytes returned 13 lines of output in 148 ms. The scan cost scales with bytes, so the 1225 ms figure belongs to 42354495 bytes, not to the tool in general.

When it earns a place

Comparing language mix across projects is the honest use. One command, one screen, 15 rows, and a clear picture of what a codebase is actually made of in 1225 ms.

For a single-file line count, find /c or an editor's status bar is already there. The tool pays off when you need comments and code separated across thousands of files, which is what the 9679 comment lines and 22027 blank lines in this scan represent.