In the previous post How do you count your number of Lines Of Code (LOC) ?, we explained how to count the LOC of a C# and .NET application. Let’s now explain why this is useful.
LOC and Productivity Misconceptions
Many developers feel uneasy about LOC because some companies wrongly use it to measure productivity. This is misleading:
- A developer can write 1,000 LOC in a day by creating a form through a designer with many controls.
- Fixing a complex bug might take two days but involve changing just one line of code.
LOC has nothing to do with productivity, but it serves other valuable purposes.
1. LOC Helps Measure Test Coverage
Test coverage is calculated as a fraction of LOC. Without knowing the total LOC, it’s impossible to determine how well-tested your codebase is. Tools like dotCover, OpenCover, Cobertura, Coverlet, NCrunch… that measure code coverage during unit tests use sequence points as execution units. NDepend imports code coverage data and integrates it seamlessly, aligning it with its logical LOC calculations.
2. LOC Aids Software Estimation
LOC, especially logical LOC, is an essential metric for estimating software. Estimation is notoriously challenging in software development. In his book Software Estimation: Demystifying the Black Art, Steve McConnell highlights LOC as one of the best ways to compare applications built under similar conditions.
This comparison helps with planning new development, refactoring, or migrations. For example:
- The Windows 10 codebase (~50M LOC) is about 60 times larger than the .NET Framework (~800K LOC).
- Knowing this difference helps gauge the effort required for similar projects.
The Complexity of Software Estimation
It’s important to note that estimation isn’t directly proportional to LOC. Larger codebases are costlier to maintain and require more effort to add new features.
Counting LOC may not measure productivity, but it is a powerful tool for analysis, estimation, and planning in software development.