GO — Healthy across the board

• Last commit 3d ago
• 18 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

scc is a high-performance Go-based code counter that analyzes source code to compute lines of code (LOC), blank lines, comments, and physical lines across 100+ languages. Unlike cloc or sloccount, it uniquely combines speed, COCOMO cost estimation, cyclomatic complexity calculation, and ULOC (unique lines of code) metrics for DRYness analysis—all in a single CLI tool. Flat monolith with cmd/badges/ as a secondary tool. Core logic resides in the root directory with main package files, language definitions, and counter logic. The ./examples/ directory contains test fixtures (complexity/, duplicates/, countas/, generated/). CI/CD configs in .github/workflows/ and deployment via .goreleaser.yml. Go module at github.com/boyter/scc/v3.

DevOps engineers, tech leads, and software architects who need fast, accurate code metrics for large codebases—particularly those managing legacy code audits, estimating project costs via COCOMO, or enforcing code quality gates in CI/CD pipelines. Also targets researchers studying code complexity and duplication patterns.

Highly mature and production-ready. The project has comprehensive CI/CD via GitHub Actions (docker-publish.yml, go.yml, codeql-analysis.yml), is mentioned in Awesome Go, supports Go 1.25.2, includes test coverage reporting via coveralls.io, and maintains detailed LANGUAGES.md documentation for 100+ languages. Active maintenance evident with recent dependency updates (levenshtein, gocodewalker, mcp-go in go.mod).

Low risk. Single maintainer (boyter) is mitigated by stable, focused scope and no complex external service dependencies—only lightweight utilities (Cobra for CLI, zerolog for logging, yaml for config). Dependencies are minimal and mature (agnivade/levenshtein, spf13/cobra are well-maintained). MCP server mode addition (mark3labs/mcp-go) slightly expands surface area. No apparent breaking changes in recent history based on versioning (v3 module).

Recent additions include MCP Server Mode (Model Context Protocol integration—visible in mark3labs/mcp-go dependency), LOCOMO estimation for LLM-based development cost forecasting, and continued polyglot language support expansion. Actively pursuing scc Enterprise product (signup form in README suggests commercialization phase). CodeQL security analysis enabled.

git clone https://github.com/boyter/scc.git && cd scc && go install ./cmd/scc && scc . (or go run ./cmd/scc/main.go for the main tool; cmd/badges/ is a separate tool for generating badge output)

Daily commands: go run ./cmd/scc . (default counts current directory) or scc <path> after installation. Key flags visible in Cobra setup: --format (json/csv/html), --complexity, --cocomo, --duplicates, --exclude-dir, --skip-generated.

• cmd/badges/main.go — Entry point for the scc command-line tool; implements the core CLI interface and orchestrates the code counting workflow
• .goreleaser.yml — Release and build configuration; essential for understanding how binaries are compiled, versioned, and distributed across platforms
• LANGUAGES.md — Comprehensive language definitions and syntax rules; every contributor adding language support must understand this mapping
• .github/workflows/go.yml — CI/CD pipeline configuration; defines test, build, and quality gates that all PRs must pass
• go.mod — Dependency manifest; lists all critical libraries including Cobra (CLI), json-iterator (performance), and text processing utilities
• Dockerfile — Container image specification; defines the production deployment environment and runtime dependencies
• README.md — Project vision and feature overview; establishes the core mission of being the fastest code counter with COCOMO and complexity analysis

• File Walker (gocodewalker) (Go os/filepath, gitignore-style patterns) — Recursively traverse directory tree, apply ignore patterns, yield file paths to counter
  • Failure mode: Permission errors on directories → skips subtree; pattern errors → treated as no match
• Language Detector (LANGUAGES.md regex patterns, file extension lookup) — Map file extensions and content heuristics to language definitions; extract syntax rules
  • Failure mode: Unrecognized extension → defaults to 'unknown' language; mixed-syntax files → matches first pattern
• Line Counter (Regex state machine, streaming line reader) — Tokenize file by comment/string delimiters; count code, blank, and comment lines
  • Failure mode: Encoding errors → skips line; malformed comment nesting → counts conservatively
• Complexity Analyzer (Regex keyword matching, counter aggregation) — Scan token stream for complexity keywords (if, for, while, switch, catch); compute cyclomatic score
  • Failure mode: Unknown keyword patterns → may under-estimate; string literals with keywords → false positives
• Output Formatter (json-iterator, template rendering, printf formatting) — Serialize metrics to JSON, CSV, HTML, plaintext, or COCOMO estimate format
  • Failure mode: Invalid output format flag → defaults to plaintext; file I/O errors → writes to stdout fallback

• CLI arguments → File Walker — Directory paths and flags (--ignore, --format, --complexity) configure scanner behavior
• File system → File Walker — Read directory entries and apply .sccignore pattern matching to filter paths

Add support for a new programming language

1. Define language syntax rules in LANGUAGES.md following existing patterns (extensions, comment delimiters, multi-line blocks, string quotes) (LANGUAGES.md)
2. Add language entry to the core language registry mapping (file extensions to language name and complexity keywords) (cmd/badges/main.go)
3. Test with example files in examples/language directory matching your language's file extension (examples/language)
4. Run scc on test files and verify accuracy by comparing against examples/complexity fixtures (examples/complexity)

Add a new output format (JSON, CSV, HTML, etc.)

1. Implement formatter interface in main code with serialization logic (cmd/badges/main.go)
2. Add command-line flag for new format in Cobra command configuration (cmd/badges/main.go)
3. Add tests covering the formatter with examples/language directory inputs (cmd/badges/main_test.go)

Configure ignore patterns for specific project type

1. Create or edit .sccignore in project root with glob patterns for files to skip (.sccignore)
2. Use standard gitignore-style syntax (wildcards, negation with !) and test with your repository (.ignore)
3. Verify patterns work by running scc with --debug flag to see excluded files (cmd/badges/main.go)

• Go 1.25.2 — Provides static compilation to single binary, fast execution, and excellent standard library for text processing and concurrent file I/O
• Cobra (CLI framework) — Enables complex CLI with subcommands, flags, and help generation matching industry-standard tools like kubectl and Docker
• json-iterator/go — High-performance JSON encoding/decoding critical for output formatting and caching serialization
• boyter/gocodewalker — Fast recursive directory traversal with built-in ignore pattern support (gitignore-style)
• zerolog (structured logging) — Efficient JSON-structured logs for debugging; lower overhead than standard logging
• levenshtein distance library — Enables fuzzy-matching for duplicate detection and DRYness metrics across large codebases

• Single-file architecture with embedded language definitions vs. plugin system

  • Why: Simplifies distribution (no runtime dependencies) and deployment (single static binary)
  • Consequence: Language additions require code changes and recompilation; no dynamic plugin loading

• Pattern-based language detection via regex vs. AST parsing

  • Why: Dramatically faster performance; handles partial/malformed code without parsing overhead
  • Consequence: Lower accuracy on edge cases; some false positives in multi-syntax files (e.g., .js with embedded SQL)

• Cyclomatic complexity via keyword counting vs. full AST analysis

  • Why: Enables language-agnostic analysis without language-specific parsers
  • Consequence: Estimates are approximate; may miss or over-count in deeply nested conditionals

• Concurrent file processing with goroutines vs. sequential scan

  • Why: Enables scanning 1000s of files efficiently on multi-core systems
  • Consequence: Memory usage scales with concurrency; requires careful goroutine pool management

• Does not perform static code analysis (linting, security scanning); delegates to external tools like CodeQL
• Does not provide IDE integration or real-time editor feedback; CLI-only tool
• Does not track historical metrics or version control diffs; counts snapshots only
• Not a code formatter or style enforcer; read-only analysis tool
• Does not require database or backend services; fully offline and stateless

No hidden env vars or service dependencies. One non-obvious detail: .ignore and .sccignore are both supported (see .sccignore in repo root), with specific precedence rules not visible in file list—check CONTRIBUTING.md or code. Language detection is suffix-based with fallback heuristics; ambiguous extensions (e.g., .jsp in examples/countas/) may require explicit --count-as flag. Complexity calculation requires AST parsing per language—missing language definitions silently skip complexity (not an error). MCP Server Mode (new) may require external MCP client setup not documented in visible README snippet.

• COCOMO (Constructive Cost Model) — scc uniquely estimates project effort and cost in person-months from LOC; understanding COCOMO parameters (effort multiplier, scale factors) is essential to interpreting scc's cost forecasts
• Cyclomatic Complexity — scc calculates complexity similar to McCabe's metric to flag unmaintainable code; this is a key differentiator from simple LOC counters and directly impacts COCOMO effort estimates
• Levenshtein Distance — scc's duplicate detection uses agnivade/levenshtein to compute string similarity between code blocks; understanding edit distance is crucial to tuning duplicate thresholds
• Abstract Syntax Tree (AST) Parsing — scc parses language-specific ASTs to count complexity and distinguish code from auto-generated sections; the language definitions in LANGUAGES.md encode AST patterns for each supported language
• ULOC (Unique Lines of Code) — scc's DRYness metric (Unique/Total LOC ratio) quantifies code duplication; lower ULOC% indicates poor maintainability and higher technical debt
• Model Context Protocol (MCP) — New MCP Server Mode (mark3labs/mcp-go in go.mod) allows scc to integrate with LLM agents and IDEs; understanding MCP is critical for the enterprise/AI integration roadmap
• DRYness / Code Duplication Metrics — scc uniquely produces ULOC and duplicate detection reports; understanding how scc groups identical/similar code blocks is essential to acting on duplication warnings in legacy systems

• AlDanial/cloc — Direct predecessor and competitor; scc was built to outperform cloc on speed while adding complexity and COCOMO metrics
• XAMPPRocky/tokei — Rust-based alternative sloc counter; comparable feature set but different language (tokei is faster on some benchmarks, scc is pure Go with no C FFI)
• boyter/gocodewalker — Sibling project by same author; provides the recursive file walking and .ignore/.sccignore filtering engine that scc depends on
• boyter/simplecache — Lightweight in-memory cache utility by same author used internally by scc for performance optimization (visible in go.mod)
• spf13/cobra — Not a direct competitor but core dependency; understanding Cobra's command structure is essential to extending scc CLI

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for language detection and file classification logic

The repo has examples for testing edge cases (issue114-issue214 directories) but lacks dedicated unit tests for the file classification system. With LANGUAGES.md documenting supported languages and the examples directory containing test cases for complexity, duplicates, and counter-as functionality, there's a clear gap in formalized test coverage that validates language detection, comment pattern matching, and blank line counting across different file types.

• [ ] Create processor_test.go or language_test.go in the root with tests for LANGUAGES.md supported formats
• [ ] Add test cases using example files from examples/complexity, examples/duplicates, and examples/countas directories
• [ ] Write table-driven tests for edge cases documented in examples/issue* directories (e.g., issue114 for .ignore files, issue152 for generated code)
• [ ] Validate comment detection, blank line counting, and complexity calculations match expected outputs
• [ ] Ensure coverage report is generated and tracked in CI (complement existing go.yml workflow)

Add GitHub Action workflow to validate scc output against benchmark baseline

The repo has benchmark.sh and benchmark_to_chart.py scripts plus .goreleaser.yml for releases, but the CI workflow (go.yml) doesn't validate performance regressions. A new workflow could run scc against the examples/ directory and compare output consistency across commits, ensuring code counter accuracy doesn't regress.

• [ ] Create .github/workflows/benchmark-validation.yml workflow file
• [ ] Add step to run scc against examples/ directory with --format json output
• [ ] Store baseline benchmark metrics from main branch (using actions/cache or artifacts)
• [ ] Compare PR results against baseline and fail if accuracy metrics (SLOC, comment counts) deviate beyond threshold
• [ ] Post results as a comment on PRs using GitHub Actions summary

Document and add tests for COCOMO/LOCOMO estimation feature behavior

The README mentions 'COCOMO calculation like sloccount' and 'LOCOMO estimation for LLM-based development costs' but there's no visible documentation in LANGUAGES.md or CONTRIBUTING.md explaining how these estimates are calculated or what test cases validate them. The dependencies include mark3labs/mcp-go suggesting MCP protocol integration, but estimation logic test coverage is unclear.

• [ ] Add section to LANGUAGES.md or create ESTIMATION.md documenting COCOMO/LOCOMO calculation methodology
• [ ] Create estimator_test.go with unit tests for COCOMO parameters (person-months, cost, schedule estimation)
• [ ] Add integration test validating LLM cost estimation with example codebases from examples/ directory
• [ ] Document any assumptions or limits on COCOMO model applicability (project size ranges, development type)
• [ ] Ensure tests validate behavior referenced in cmd/ structure (badges/main.go may output estimation metrics)

• Add integration tests for the new MCP Server Mode (mark3labs/mcp-go integration) in cmd/scc/main_test.go—no visible test coverage for MCP protocol handshakes yet
• Expand LANGUAGES.md documentation with examples showing how to customize comment/string patterns for ambiguous language variants (e.g., .tpl files that could be Go Template or plain HTML—currently listed as Go Template in header)
• Create benchmark comparison against tokei (Rust alternative) and cloc in benchmark.sh—currently benchmark_to_chart.py exists but main bash benchmark may lack recent baseline data for the COCOMO/LOCOMO cost estimation features

The scc project has a generally secure codebase with no critical vulnerabilities detected. The main security concerns are infrastructure-related: outdated base images (Go 1.25.2 and Alpine 3.22) should be kept current, and Docker best practices (non-root user execution) should be implemented. The project lacks visible container image scanning in the CI/CD pipeline. Dependencies appear legitimate and well-maintained. No hardcoded secrets, injection risks, or SQL/XSS vulnerabilities were identified in the visible file structure. Recommend implementing automated dependency and base image updates, adding container scanning to GitHub Actions, and following Docker security best practices.

• Medium · Outdated Go Version in Dockerfile — Dockerfile. The Dockerfile uses Go 1.25.2, which may contain known vulnerabilities. Go releases security updates regularly, and using outdated versions exposes the build to potential exploits. Fix: Keep Go version up-to-date. Monitor golang.org/dl for security releases and update the base image version regularly. Consider implementing automated dependency updates.
• Medium · Outdated Alpine Base Image — Dockerfile. Alpine 3.22 may accumulate security vulnerabilities over time. Alpine images are regularly patched, and using older versions increases exposure to known CVEs. Fix: Regularly update the Alpine base image to the latest stable version. Implement automated base image updates and vulnerability scanning in CI/CD pipeline.
• Low · Missing Docker Security Best Practices — Dockerfile. The Dockerfile does not specify a non-root user, which means the container runs as root by default. This is a security anti-pattern. Fix: Add a non-root user and switch to it before running the application. Example: 'RUN addgroup -S appgroup && adduser -S appuser -G appgroup && USER appuser'
• Low · No Container Image Scanning — .github/workflows. The provided configuration does not show evidence of container image vulnerability scanning in the CI/CD pipeline. Fix: Integrate container image scanning tools (e.g., Trivy, Grype) into the GitHub Actions workflow to automatically detect vulnerabilities in published images.
• Low · Potential Dependency Confusion — go.mod. The go.mod file uses a custom domain (github.com/boyter/) for internal dependencies. Ensure package names are properly scoped to prevent potential dependency confusion attacks. Fix: Verify that all dependencies in go.mod are from trusted sources. Consider using GOVCS or similar tools to restrict module sources. Regularly audit dependencies for security updates.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/boyter/scc shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live boyter/scc repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/boyter/scc.

What it runs against: a local clone of boyter/scc — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in boyter/scc | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of boyter/scc. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/boyter/scc.git
#   cd scc
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of boyter/scc and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "boyter/scc(\\.git)?\\b" \\
  && ok "origin remote is boyter/scc" \\
  || miss "origin remote is not boyter/scc (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "cmd/badges/main.go" \\
  && ok "cmd/badges/main.go" \\
  || miss "missing critical file: cmd/badges/main.go"
test -f ".goreleaser.yml" \\
  && ok ".goreleaser.yml" \\
  || miss "missing critical file: .goreleaser.yml"
test -f "LANGUAGES.md" \\
  && ok "LANGUAGES.md" \\
  || miss "missing critical file: LANGUAGES.md"
test -f ".github/workflows/go.yml" \\
  && ok ".github/workflows/go.yml" \\
  || miss "missing critical file: .github/workflows/go.yml"
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/boyter/scc"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.