CLOC for .NET Repositories

Trigger On

• the repo wants cloc
• the team needs repeatable LOC, language, or branch diff statistics for a .NET repo
• the user asks about C# codebase size, solution composition, or code-count deltas between refs

Workflow

1. Choose the counting mode deliberately:

- --vcs=git for repo-respecting counts - path-based counting for bounded folders - --git --diff BASE HEAD for change deltas

1. Prefer .NET-relevant views first:

- C# footprint - test versus production footprint - solution language mix such as C#, Razor, XML, JSON, YAML, and MSBuild files

1. Exclude noise before trusting the numbers:

- bin - obj - .git - vendored or generated folders when they are not part of the decision

1. Use machine-readable output when the numbers feed docs, CI, or follow-up automation:

- --json - --csv - --yaml - --md

1. Treat cloc as a sizing and comparison tool, not as evidence that the design is good.
2. When using diff mode, compare named refs that match the review question:

- origin/main..HEAD - release branch versus main - before and after a refactor

1. After any code cleanup based on cloc findings, run the repo's normal quality pass.

Deliver

• repeatable LOC and language-mix reporting for .NET repos
• explicit include and exclude rules
• branch-diff or bounded-scope commands that answer a concrete engineering question

Validate

• counts match the intended source boundary instead of including build output noise
• command choice matches the reporting question
• any automation or docs that consume the numbers can rerun the same command
• cloc is used as context, not as a substitute for tests or design review

Load References

Related skills