Export Code Metrics to CSV for Multi-Language Projects

It's 11 PM and Your CTO Wants Code Stats by Morning

You're staring at a sprawling codebase that spans Python, TypeScript, Rust, and a few lingering PHP files from a legacy migration nobody wants to touch. Your CTO just pinged you on Slack asking for a breakdown of code distribution across languages by tomorrow's leadership meeting. The request seems simple enough until you realize there's no single dashboard, no unified report, and certainly no clean CSV file ready to import into Google Sheets.

We've all been there. Multi-language projects are the norm in modern development, but they create a unique headache when stakeholders want quantifiable metrics. Each language ecosystem tends to live in its own world, with its own tooling, its own conventions, and its own way of counting what matters. Getting all of that into one tidy spreadsheet feels like herding cats.

The Problem: Fragmented Code Metrics Across Language Silos

Most teams don't run a single language. A typical SaaS product might have a Node.js backend, a React frontend, a Python data pipeline, some Go microservices, and infrastructure code in HCL. When leadership asks "how much code do we actually maintain?" you need an answer that covers all of it.

The problem compounds quickly. Running cloc on your Python directory gives you one set of numbers. Your frontend lead swears by a different tool. The DevOps team tracks infrastructure separately. By the time you try to merge everything manually, you're copy-pasting numbers into a spreadsheet at midnight, and you've already made two transcription errors.

What you need is a reliable way to export code statistics to CSV for multi-language projects in one pass, with consistent metrics across every language in your repository.

Why This Happens: The Root Causes

Tool Proliferation Without Coordination

The developer tooling landscape is rich but fragmented. tokei is blazing fast but written in Rust and not everyone has it installed. scc is powerful but has its own output format. cloc is the old reliable workhorse but can be slow on massive repositories. Each tool produces slightly different counts because they handle edge cases differently.

For example, a 450,000-line codebase might report 432,118 lines in cloc and 441,502 in tokei depending on how each handles blank lines, comment styles, and embedded code in template files. That 9,384-line discrepancy is enough to make stakeholders question your numbers.

Inconsistent Language Definitions

What counts as "TypeScript"? Does it include .tsx files? What about TypeScript declarations in .d.ts files? Different tools answer these questions differently, and when you're merging reports manually, these inconsistencies create silent errors in your final spreadsheet.

No Native Cross-Language CSV Export

Most code metric tools can output to CSV, but they do it per-run. If your repository has mixed languages, you get one CSV with everything lumped together or you run the tool multiple times on different directories and end up with fragmented files that don't share a consistent schema.

The Solution: A Systematic Approach to Unified CSV Export

Here's a practical, step-by-step method to get clean, consistent code statistics exported to CSV across every language in your project.

Step 1: Choose One Tool and Standardize It

Pick a single code counting tool and use it across your entire repository. For multi-language projects, cloc and tokei are the two strongest candidates because they both support 100+ languages out of the box.

If you prioritize speed, go with tokei. On a mid-sized monorepo with 2.3 million lines across 14 languages, tokei typically completes in under 3 seconds while cloc might take 45 seconds or more. If you prioritize widespread availability and detailed reporting, cloc is available in most package managers and produces richer breakdowns.

The key is consistency. Don't mix tools between runs or between projects. Pick one, document the version, and stick with it.

Step 2: Run the Tool Across Your Entire Repository Root

Don't run separate passes per language directory. Instead, point your chosen tool at the repository root and let it auto-detect languages. This ensures consistent counting rules and a single output file.

For cloc, the command looks like this:

cloc --by-file --csv --out=code_stats.csv ./

For tokei, you'd use:

tokei ./ --output code_stats.csv

Both commands produce a CSV file, but the schemas differ. cloc gives you columns like Language,Files,Blank,Comment,Code. tokei provides Language,Files,Lines,Code,Comments,Blanks. Know your schema before you start transforming data.

Step 3: Filter and Transform for Multi-Language Clarity

The raw CSV export often includes noise. You'll see entries for "SUM" rows, header metadata, or languages with trivial file counts that don't matter to stakeholders. Clean this up.

If you're working with cloc's output, strip the summary rows and keep only per-language entries. A quick pass with awk or a Python script can normalize the data:

awk -F',' 'NR>2 && $1!="Language" && $1!="SUM" {print}' code_stats.csv > clean_stats.csv

For teams that want a more robust pipeline, a short Python script using the csv module gives you full control over filtering, column renaming, and even adding derived metrics like comment-to-code ratios.

Step 4: Add Contextual Columns Stakeholders Actually Want

Raw line counts are rarely enough. Leadership usually wants context. Consider enriching your CSV with additional columns:

• Repository — useful if you're aggregating across multiple repos
• Timestamp — for tracking trends over time
• Comment-to-Code Ratio — a quick health indicator (calculate as Comments / Code)
• Primary Framework — helps non-technical stakeholders understand what each language block represents

For instance, if your Python code has 89,432 lines of code and 12,108 lines of comments, your comment-to-code ratio is roughly 13.5%. That's a meaningful number for engineering managers tracking documentation health.

Step 5: Automate the Export for Recurring Reporting

Once you have a working pipeline, wrap it in a script. A simple shell script or Makefile target that runs the counter, cleans the output, and enriches the CSV turns a 30-minute manual chore into a 5-second command.

For teams using CI/CD, you can schedule this as a weekly job. Store the CSV artifacts in a shared location or push them to a metrics dashboard. Over time, you build a historical dataset that shows how your codebase evolves, which languages are growing, and where technical debt might be accumulating.

Step 6: Validate Your Numbers

Before presenting anything, sanity-check your output. Compare the total file count against what git ls-files | wc -l reports. If there's a significant gap, you might be excluding files through .gitignore patterns or counting generated code that shouldn't be included.

A common gotcha: node_modules, vendor directories, and build artifacts can inflate numbers dramatically. Always configure your tool to ignore these. In cloc, use --exclude-dir=node_modules,vendor,dist,build. In tokei, add a .tokeignore file.

Making Code Metrics Work for You

Exporting code statistics to CSV for multi-language projects doesn't have to be a midnight scramble. The combination of a single reliable tool, a clean transformation step, and light automation gives you consistent, trustworthy numbers whenever anyone asks.

The real value isn't just in producing a spreadsheet. It's in building a repeatable process that scales as your codebase grows and your language count climbs. When your next CTO request lands in Slack at 11 PM, you'll already have the answer ready.