# scc (Sloc Cloc and Code): a Go code counter with complexity and COCOMO estimates > scc counts lines, comments and blanks across many languages, adds complexity scoring, COCOMO and LOCOMO estimates, and ships an MCP server mode. It is a fast single binary, but the estimation features are heuristics, not measurements. **boyter/scc** — Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go. - Repository: https://github.com/boyter/scc - Stars: 8,780 · Forks: 347 - Language: Go - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/boyter-scc ## What scc counts that cloc does not scc is a line counter in the same family as cloc, sloccount and tokei. The README describes the goal as being "the fastest code counter possible" while also performing COCOMO calculation like sloccount, LOCOMO estimation for LLM-based development costs, complexity estimation similar to cyclomatic complexity calculators, and unique lines of code (ULOC) or DRYness metrics. That combination is the differentiator. A plain counter answers how big a codebase is. scc also answers how repetitive it is, how much of it is generated, and what a costing model would say about it. The audience is engineers and engineering managers who need those numbers without wiring up several tools. A build engineer checking whether a repository is growing. A consultant estimating a migration. A platform team tracking technical debt across many repos. scc produces all of that from one command, and the binary is small enough to drop into a container or a CI job. The README also states that scc powers searchcode.com, which is the strongest signal about the project's intended scale: it is used on large, heterogeneous codebases rather than toy directories. The name is deliberately short so it is easy to type, and the README offers Succinct Code Counter as an expansion for anyone who dislikes the original. ## How the counting, complexity and ULOC pipeline fits together The repository layout tells most of the story. main.go and config.go sit at the root next to languages.json and LANGUAGES.md. The processor/ directory holds the counting logic, packages/ holds shared code, and mcp.go implements the MCP server mode. A vendor/ directory is checked in, so the build does not need to fetch modules. Dependencies in go.mod are ordinary: cobra and pflag for the command line, go-git for the git insight reports, mark3labs/mcp-go for the MCP server, and boyter/gocodewalker for walking the file tree. File discovery happens first, filtered by ignore rules. The repository ships a .ignore file and a .sccignore file, and the README has a Configuration Files section, so ignore behaviour is configurable rather than hardcoded. After discovery, each file is matched to a language definition drawn from languages.json, then classified into code, comment, blank and physical lines. The complexity estimate is computed during that same pass, which is why it is cheap: there is no second parse. The README is explicit that this is an estimate "similar to cyclomatic complexity calculators" rather than a language-aware AST analysis. ULOC is computed by hashing or comparing lines to find duplicates, which is how the DRYness metric is derived. COCOMO and LOCOMO then turn the line counts into cost figures. Every one of those stages consumes the same line totals, so an error in language detection propagates into the complexity, ULOC and cost numbers at once. ## Installing scc and running a first count The README lists many install paths. The Go toolchain route needs Go 1.25 or newer, and the module path carries the v4 major version: ```bash go install github.com/boyter/scc/v4@latest ``` After that, scc is in $GOPATH/bin. Package managers cover the common platforms: brew install scc on macOS and Linux, scoop install scc or choco install scc on Windows, winget install --id benboyter.scc --source winget, sudo snap install scc on Ubuntu, sudo port install scc via MacPorts, and pkg install scc on FreeBSD. The README notes one snap caveat: snap-installed applications cannot run outside /home, so you may hit permission errors when scanning a tree elsewhere. If you would rather not install anything, the README gives a Docker invocation that mounts the current directory read-only and disables networking: ```bash docker run --rm -it -v "$PWD:/pwd:ro" --network none ghcr.io/boyter/scc:master scc /pwd ``` The first real use is to point scc at a directory and read the table it prints. Run it from the root of the repository you care about: ```bash scc . ``` The output is a per-language table with lines, blank lines, comment lines, code lines and a complexity column, followed by a total row. If a language you expect is missing, the file extension is not in languages.json; LANGUAGES.md lists what is supported. For a machine-readable result, the README documents an Output Formats section, and the repository ships an SCC-OUTPUT-REPORT.html as an example of the HTML report the tool can generate. ## Where scc's numbers stop being measurements The complexity column is the weakest part of the output, and the README does not pretend otherwise. It is described as an estimate similar to cyclomatic complexity calculators, computed during the counting pass. A language-specific tool that builds a syntax tree will disagree with scc, sometimes by a wide margin, because branch constructs are recognised by pattern rather than by grammar. If your team enforces a complexity threshold per function, scc's number is the wrong number to enforce. Language detection is the second soft spot. Files are matched to definitions in languages.json, so an unusual extension, a template language, or a file that mixes two syntaxes can be misclassified, and the miscount then flows into the complexity, ULOC and COCOMO figures. The examples/ directory is telling here: it contains directories named issue114, issue115, issue120, issue149, issue152, issue214, issue260, issue323, issue339, issue345, issue379, issue552, issue564 and issue610, alongside complexity/, countas/, duplicates/, generated/, minified/, long/ and oneline/. Those are regression fixtures for exactly this class of edge case, which is a sign the maintainer treats misclassification as a real problem rather than a rounding error. Generated and minified files are the third trap. The examples/generated/ and examples/minified/ fixtures exist because those files inflate line counts and destroy ULOC ratios. scc ships .sccignore for this reason, but the ignore file is only as good as what you put in it. A repository that vendors dependencies and does not exclude them will report a codebase far larger than the one the team actually writes. ## scc against tokei, cloc and language-specific complexity tools The README names the alternatives directly: SLOCCount, cloc, gocloc, loc, loccount, polyglot, tokei, sloc and stto. The meaningful comparison is with tokei, because both are fast counters written in compiled languages (scc in Go, tokei in Rust) and both aim at the same job. The difference is scope. tokei counts lines. scc counts lines and then layers complexity, ULOC, COCOMO and LOCOMO on top, which is why the README calls it "one tool to rule them all". If you only want line counts, tokei is the leaner choice and has fewer moving parts to reason about. cloc is the other reference point, and the README notes it was inspired by SLOCCount and implemented in Perl for portability. That portability is cloc's advantage: it runs anywhere a Perl interpreter exists, with no binary to build. scc trades that for a compiled binary and speed. If your environment cannot ship a compiled artefact, cloc remains the pragmatic option. For complexity specifically, the honest alternative is a language-native analyser rather than another counter. scc's complexity figure is a generic approximation across all supported languages; a tool that parses one language properly will be more accurate for that language. The trade is coverage against precision. scc gives you a comparable number for every language in the tree, which no single-language tool can do. ## Maintenance, licence and the commercial roadmap scc is MIT licensed, which permits commercial use, modification and redistribution with the licence text retained. This article does not give legal advice; read the LICENSE file in the repository before shipping scc inside a product. One practical note: the repository vendors its dependencies in vendor/, so a source build does not depend on module downloads at build time. The last push to the default branch was on 2026-08-24, the same day v4.0.0 was released. Before that, v3.7.0 landed on 2026-03-04 and v3.6.0 on 2025-10-31. That is a release cadence of roughly every five to eight months, with the v4 major bump being the most recent event. The repository is not archived. A major version bump means the module path carries /v4, so upgrading from v3 requires changing the import path if you use scc as a library, and it is worth reading the release notes before moving a pinned version in CI. The README also states that an enhanced commercial version, scc Enterprise, is being explored, aimed at historical analysis, team-level dashboards and policy enforcement, with a private beta interest form linked. That is a stated intention, not a shipped product. Nothing in the repository indicates which features would move behind it, and the README says the core tool will remain free and open for individual developers. Teams evaluating scc for a long-lived internal platform should treat that as an open question rather than a settled one, because feature boundaries between an open core and an enterprise tier are exactly what tends to shift. ## Running scc as an MCP server for agent workflows The repository contains mcp.go and mcp_test.go, and the README has an MCP Server Mode section, so scc can expose its counting as tools over the Model Context Protocol rather than only as a CLI. The dependency list confirms this is a first-class feature: mark3labs/mcp-go is a direct requirement in go.mod, not an indirect one. This matters because the README frames the project's positioning around agents, describing scc as powering searchcode.com for "structured code intelligence over any repo, built for AI agents". An agent that needs to know how large a repository is, which languages dominate it, or how repetitive it is can call scc instead of walking the tree itself. The practical constraint is that MCP mode is a separate surface from the CLI, and the README does not document the available tools in the excerpt available here, so you should read the MCP Server Mode section and mcp.go before wiring it into an agent. The counting semantics are the same as the CLI, which means the complexity and language-detection caveats above apply unchanged to anything an agent reports back. ## Conclusion Adopt scc if you need a single static binary that reports lines, comments, blanks, complexity, ULOC and COCOMO across a polyglot repository, and you are comfortable reading the estimates as heuristics. Do not adopt it if you need an authoritative complexity gate for a specific language; scc's complexity number is a generic approximation, not a language-specific parser's result. Before rolling it into CI, verify the language list in LANGUAGES.md covers the file types in your tree, check that .sccignore excludes generated code, and confirm the reported COCOMO figures against a costing model your finance team already accepts. ## FAQ ### What is Sloc, Cloc and Code (scc)? scc is a code counter written in Go, similar to cloc, sloccount and tokei. It counts lines of code, blank lines, comment lines and physical lines across many languages, and adds complexity estimates, unique lines of code metrics, and COCOMO and LOCOMO cost estimates. ### What is SCC coding? In this context SCC refers to the tool scc, short for Sloc Cloc and Code, which the README also expands as Succinct Code Counter. It is a command line program that reports line counts and complexity estimates for a codebase. ### How do you calculate code complexity? scc calculates complexity during the same pass that counts lines, and the README describes the result as an estimate similar to cyclomatic complexity calculators rather than a full syntax-tree analysis. That means it is comparable across languages but may differ from a language-specific analyser. ### Is a cyclomatic complexity of 20 considered high? The scc documentation does not define thresholds or give guidance on what counts as high complexity, so it cannot answer this. The tool reports a complexity figure per language and in total, and any threshold has to come from your own team's standard. ## Sources - [Official README](https://github.com/boyter/scc#readme) - [Project repository](https://github.com/boyter/scc) - [Release notes](https://github.com/boyter/scc/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/boyter-scc