Skip to content

Lines of Code

Simply put, Lines of Code (LOC) is a software metric used to measure the size of a codebase by counting the number of lines in the source code files. It is often used to estimate the complexity, maintainability, and development effort required for a software project.

What it Measures

Total number of lines in the source code files, methods, and members.

How it's Measured

Count all lines in the source code files.

Why it helps

  • Provides a basic measure of codebase size.
  • Long functions tend to do too much; correlate with defects and test difficulty.
  • Helps in estimating development effort and project scope.
  • Can be used to track code growth over time.
  • Aids in identifying potential areas for refactoring or simplification.

LOC Statistics: Size as a Signal

LOC doesn’t measure quality, but it does correlate with scope, review time, and risk. Huge files often hide multiple responsibilities, intertwine concerns, and make parallel work harder. Use LOC to prompt a conversation: “Can we split this so each part has a clear purpose?”

1. Split by responsibility

Smaller modules create seams where tests, ownership, and performance work can focus. Reviewers can specialize, and changes stop colliding. This also helps incremental refactors, move one responsibility at a time.

// 800-line Service.scala: routing, validation, business logic, persistence
object Service {
  // ...
}

object Routes     // HTTP/Wire concerns
object Validate   // pure checks
object Domain     // business rules
object Store      // persistence

Tip

Smaller modules reduce blast radius and accelerate reviews.

2. Exclude generated and vendored code

Generated code (protobufs, SDKs) distorts metrics and hides real signals. Configure your analyzer to exclude these directories and commit that configuration. Now your metrics reflect code you actually maintain.

3. Use LOC with churn to find hotspots

A medium‑sized file that changes constantly can be riskier than a large but stable one. Pair LOC with recent change count to prioritize attention. Many teams find 20% of files absorb 80% of maintenance pain. Start there.