3 Code Statistics Mistakes Ruining Open Source Audits

Quick win before we begin: run git log --shortstat --author="$(git config user.name)" --since="3 months ago" right now. That single line just gave you a rough commit-and-LOC baseline in under two seconds. Now let's talk about why that's not nearly enough — and how to do it properly.

If you're an open-source maintainer preparing a quarterly impact report for your fiscal sponsor, foundation grant, or corporate backer, you already know the drill. Someone in a spreadsheet asks: "How much code did the project produce this quarter?" And suddenly you're scrambling to generate code statistics that don't make your project look either artificially inflated or suspiciously dormant.

I've reviewed two dominant approaches to generating LOC reports for open source projects: the quick-and-dirty shell-script method (Approach A) and the structured-tooling method using dedicated code metrics tools like cloc, scc, or gitui-adjacent analyzers (Approach B). Both camps make predictable mistakes. Let's walk through each one — and fix them.

Mistake #1: Counting Every Line as If Blank Lines Were Code

The Problem

Approach A folks love wc -l. It's fast. It's universal. It's also wildly misleading. A JavaScript file with 40 blank lines and 15 inline comments still reports as "55 lines of code." When you're reporting lines of code to a sponsor who's evaluating project velocity, that's not a metric — it's a vanity number.

The Fix

Use cloc or scc — both distinguish between code, comment, and blank lines. Here's a real example from a mid-sized Rust CLI project I audited last month:

• wc -l reported: 14,832 total lines
• cloc reported: 9,114 code lines, 3,201 comments, 2,517 blank

That's a 38% inflation. Approach B wins this round cleanly. The sponsor sees 9,114 — and that number actually means something.

Mistake #2: Ignoring File-Type Filtering (The Node_modules Disaster)

The Problem

Both approaches stumble here, but Approach A face-plants harder. Running a recursive line count without exclusion patterns means your codebase metrics include vendored dependencies, generated files, lockfiles, and minified bundles. I've seen maintainers proudly report "120,000 lines of code" when 104,000 of those lines lived in package-lock.json and a bundled dist/ folder.

The Fix

Approach B tools handle this natively. scc respects .gitignore by default. cloc accepts --exclude-dir and --not-match-f flags. Set up a consistent exclusion profile:

cloc --exclude-dir=node_modules,dist,build,vendor --exclude-ext=json,lock src/

For repository statistics that you'll report repeatedly, codify this in a Makefile target or a shell script in your repo's scripts/ directory. Consistency matters more than the specific tool you pick.

Mistake #3: One-Time Snapshots Instead of Trended Data

The Problem

Approach A treats code analysis as a one-shot event. You run the command, paste the number into a report, and forget about it until next quarter. The problem? A single snapshot tells you nothing about trajectory. A project that went from 8,000 to 9,000 LOC looks identical to one that went from 15,000 to 9,000 (after a major refactor) — if you only capture the endpoint.

The Fix

Approach B practitioners commit to trended reporting. Generate weekly or monthly snapshots and store them. Two practical ways:

1. GitHub Actions workflow: Schedule cloc --json output to a metrics branch every Monday. Diff it against last week's JSON.
2. Git-history-based analysis: Use gitstats or git-fame to generate git stats that show contribution velocity over time — commits per author, lines changed per week, file churn rates.

The trended approach catches something a snapshot never will: a project that's technically growing in LOC but has had only one contributor for six months. That's a sustainability red flag your sponsor actually cares about.

Mistake #4: Reporting Raw LOC Without Context

The Problem

This is where Approach B people get lazy too. They generate beautiful code statistics dashboards — language breakdowns, file counts, comment ratios — and then hand the raw output to non-technical stakeholders. A foundation program officer doesn't know what "comment density: 22%" means. They don't care.

The Fix

Translate. Every LOC number in your report should answer a stakeholder question:

• "9,114 lines of Rust across 47 source files" → "The codebase is small enough for a single contributor to maintain context across the entire project."
• "3,201 comment lines (26% comment density)" → "Documentation is embedded in the code — onboarding new contributors requires less external documentation overhead."
• "47 contributors over 12 months, top 5 responsible for 68% of commits" → "The project has a healthy contributor pipeline but depends on a core team — bus factor of 5."

The code metrics are the evidence. The narrative is the report. Approach A gives you neither; Approach B gives you the evidence but stops short. The real win is Approach B + translation.

Mistake #5: Forgetting Non-Code Contributions Entirely

The Problem

Both approaches systematically undervalue open-source work that isn't source code. Documentation, issue triage, CI configuration, Dockerfiles, test fixtures — these are the connective tissue of a healthy project. If your LOC report only counts .rs or .py files, you're underreporting project activity by 30-50%.

The Fix

Run two passes:

1. Code LOC: cloc --include-lang=Rust,Python,Go src/ lib/
2. Project-wide LOC: cloc --exclude-dir=node_modules,dist . (captures Markdown, YAML, Dockerfile, TOML, etc.)

Report both. The delta between them tells a story: a project where project-wide LOC is 3x the code LOC is investing heavily in documentation and infrastructure. That's a signal of maintainability — exactly what a sponsor evaluating long-term viability wants to see.

Mistake #6: No Reproducibility — Numbers Nobody Can Verify

The Problem

Approach A's fatal flaw: the maintainer runs cloc on their laptop, pastes numbers into a Google Doc, and nobody can reproduce the exact figure three months later. Different cloc versions, different file states, different exclusion lists — the code statistics drift.

The Fix

Pin everything:

• Pin your tool version (cloc v1.98, scc v3.1.0)
• Pin your exclusion config in a committed file
• Pin the commit SHA you're measuring against
• Output JSON, not human-readable text — it's diffable and machine-parseable

When your sponsor asks "where did 9,114 come from?", your answer should be: "Commit a3f7b2c, cloc v1.98, config in scripts/metrics.sh, raw JSON in docs/metrics/2024-Q3.json." That's not just a number. That's an auditable code metrics pipeline.

The Verdict

Approach A — ad-hoc shell commands — is fine for a quick gut check. I still use git log --shortstat weekly. But for anything that lands in a sponsor report, a foundation grant renewal, or a public transparency dashboard, Approach B with the six fixes above is the only defensible path. The difference between "we wrote some code" and "here's a reproducible analysis of our project's codebase health" is about two hours of setup — and it's the difference between looking amateurish and looking like a project worth funding.

Your sponsors aren't buying lines of code. They're buying confidence that you understand your own project. LOC reports done properly are proof of that understanding. Done poorly, they're just noise.