scc: A Fast Code Counter That Trades Some Accuracy for Speed and Extra Metrics

What scc Solves and Who It Is For

scc is a command-line tool for counting lines of code, blank lines, comment lines, and physical lines across many programming languages. It is designed for developers and engineering leaders who need a quick, rough measure of a codebase's size without waiting for slower tools. The README states its goal is to be 'the fastest code counter possible', and it adds features that plain counters lack: cyclomatic complexity estimates, COCOMO cost calculations, LOCOMO estimates for LLM-based development costs, and unique lines of code (ULOC) for DRYness metrics. The tool is written in pure Go, which means it compiles to a single static binary and runs on Windows, Linux, and macOS. It is especially useful in CI pipelines, pre-commit hooks, or any script where you want repository metrics without pulling in a heavy dependency. The project also powers searchcode.com, so it has a real production use case beyond hobbyist counting.

How scc Works: Counting, Complexity, and Estimates

scc scans files in a directory tree, identifies the language of each file, and then parses the content to separate code, comments, and blanks. The counting mechanism is not described in detail in the README, but the project's background posts (linked in the README) explain its performance approach, which involves parallel processing and careful I/O handling. Beyond raw counts, scc computes a complexity estimate per file, similar to cyclomatic complexity, by analyzing control flow keywords. It also calculates COCOMO (Constructive Cost Model) estimates, which predict effort and cost based on lines of code, and LOCOMO, a newer estimate for LLM-based development costs. The ULOC metric counts unique lines across the codebase, giving a sense of duplication or DRYness. These extra metrics are the main differentiator from simpler counters like tokei, which only provide line counts. The output can be formatted in multiple ways, including JSON, CSV, and an HTML report, making it suitable for automated ingestion.

Getting scc Running: Installation and Basic Usage

Installation is straightforward. The README lists several package managers: `go install github.com/boyter/scc/v4@latest` for Go users (requires Go 1.25 or later), `brew install scc` for Homebrew, `sudo snap install scc` for Snap, and `sudo dnf copr enable lihaohong/scc && sudo dnf install scc` for Fedora. Windows users can use Scoop, Chocolatey, or WinGet. There is also a Docker image: `docker run --rm -it -v "$PWD:/pwd:ro" --network none ghcr.io/boyter/scc:master scc /pwd`. Once installed, running `scc` in a directory produces a summary table of languages, files, lines, blanks, comments, and complexity. The README does not list all command-line flags in the provided excerpt, but it references configuration files and output formats, implying you can customize language detection and output via config files. The tool also has a Git insight report mode and an HTML report mode, which are mentioned in the table of contents but not detailed in the excerpt. For basic use, you simply point it at a directory and read the table.

The Speed vs. Accuracy Trade-off

scc's primary selling point is speed, but that speed likely comes at the cost of accuracy. The README lists cloc, tokei, and gocloc as similar tools, and the author's blog posts (linked) discuss performance benchmarks. However, the README does not provide a formal accuracy comparison. A fast counter often uses heuristics for language detection, which can misclassify files with ambiguous extensions or unusual comment syntax. For example, a file with a `.h` extension could be C, C++, or Objective-C, and scc must guess. The README does not document how it resolves such cases. This matters if you use scc for cost estimation or COCOMO calculations, where a 10% error in line count can skew the effort estimate. The project's own description says 'accurate', but the definition of accurate is not quantified. If you need precise counts for legal or contractual reasons, you should cross-check with a slower but more rigorous tool like cloc.

COCOMO and LOCOMO: Useful Estimates or Gimmicks?

scc includes COCOMO calculations, which estimate the effort and cost to develop a codebase based on lines of code. This is a classic software engineering metric, and scc's implementation follows the same model as sloccount. The README also mentions LOCOMO, which is a newer estimate for LLM-based development costs. This is an interesting addition, as it addresses the growing use of AI coding assistants. However, the mathematical model behind LOCOMO is not described in the README, and it is unclear how it accounts for factors like prompt complexity or model token pricing. For a developer, these estimates are rough at best. COCOMO itself has known limitations, and applying it to modern codebases with frameworks and generated code can produce misleading numbers. That said, having these estimates in the same tool as the line count is convenient. You do not need to export counts to a separate spreadsheet. The LOCOMO feature is a differentiator, but treat it as a heuristic, not a budget forecast.

Limitations and When scc Is the Wrong Tool

The most obvious limitation is the Snap packaging issue: the README notes that Snap-installed applications cannot run outside of `/home`, so if you use Snap, you may encounter permission errors when scanning directories outside your home folder. This is a real constraint for CI systems that run in `/tmp` or `/opt`. Another limitation is the requirement for Go 1.25 or later if you install from source, which might be a problem on older systems. The project also has an 'Enterprise' offering that is not yet available, and the README asks for interest in a private beta. This suggests the core tool is stable, but the team is exploring commercial features like historical analysis and policy enforcement, which are not in the open-source version. If you need those features, scc alone is not enough. For very large monorepos, scc's speed is an advantage, but for small projects, the overhead of running a separate tool might not be worth it when you can use `wc -l` or a simple script. Also, scc does not appear to handle binary or minified files specially, so it may count minified JavaScript as one huge line, which can distort metrics.

Alternatives: cloc, tokei, and gocloc

The most direct alternative is cloc, which is written in Perl and is often slower but more configurable. cloc supports a wider range of languages and has a more mature language detection algorithm, including the ability to read file contents to disambiguate. tokei is a Rust-based counter that is also fast and accurate, but it does not include COCOMO or LOCOMO estimates. gocloc is another Go counter inspired by tokei, but it is less feature-rich than scc. The README lists these tools and links to performance comparisons. The key difference is that scc bundles complexity and cost estimates, which neither tokei nor gocloc provide. cloc has a `--by-file` option and can output results in many formats, similar to scc, but cloc's focus is on accuracy and portability, not raw speed. If you need a counter that runs everywhere without a Go toolchain, cloc's Perl script is easier to deploy. If you want speed and do not care about cost estimates, tokei is a solid choice. scc sits in the middle, offering speed plus extra metrics, but with a less proven track record than cloc.

Maintenance and Upgrade Considerations

scc is actively maintained, with a recent release v4.0.0 on 2026-08-24, and the master branch is the default. The project uses GitHub Actions for CI, and the README includes a link to a coverage report, though the exact percentage is not shown. The license is MIT, which is permissive and allows commercial use without restrictions. However, the v4.0.0 release is a major version bump, which likely introduces breaking changes in command-line flags or output formats. The README does not provide a changelog in the excerpt, so you should check the release notes before upgrading from v3.x. The project also has a development section in the table of contents, but the excerpt does not detail how to contribute. For a production environment, consider pinning a specific version in your scripts to avoid surprises. The Docker image tag `master` is a moving target, so use a versioned tag if you rely on it. The maintenance cost is low for individual users, but if you depend on scc in a CI pipeline, you should budget time for occasional updates to match new releases.

Editorial conclusion

Adopt scc if you need a fast, single-binary counter for everyday repository size checks, complexity estimates, or CI scripts where speed matters more than perfect accuracy. Avoid it if you require precise language detection for exotic files or if you cannot tolerate the maintenance burden of a project that changes its output format across major versions. Before relying on it, verify its language detection rules against your codebase, check the v4.0.0 release notes for any breaking changes, and test its output against cloc or tokei on a representative sample. The project's own README acknowledges it is 'similar to cloc, sloccount and tokei', so treat its numbers as estimates, not ground truth.

Official sources

1. Official README
2. Project repository
3. Release notes