ALL-MODU0001 · module_line_count

Measure how many physical lines one module holds.

This is a deterministic rule for all languages. Read its implementation.

Definition

Count every physical line of this source file, including comments, docstrings, and blank lines. Length is what a reader pays before understanding anything, and counting the lines as written is the only count that matches what they scroll through.

The measurement stops at the number. A separate policy compares it against a ceiling a project chose, such as four hundred lines, because a generated schema and a hand-written service tolerate very different lengths and only the project knows which one this is.

Evidence

The finding names the module, its exact physical line count, and how many classes and functions that length is spent on, which is what says whether a long module is one large subject or several small ones sharing a file. The repair is a choice, since splitting by line count alone produces fragments nobody can name. The value is the physical line count.

Exceptions

A generated file, a vendored dependency, a schema-heavy module, and a migration are long for reasons nobody is going to fix, so a project excludes them or judges them under a separate policy. Splitting a long module into arbitrary fragments, inheritance layers, or forwarding files makes the count smaller and the codebase worse, so a repair is worth checking against cohesion. Pylint C0302 measures the same thing, so a project already running it with the same ceiling should disable one of the two.

Examples

A four-hundred-and-one-line module returns 401 and a three-hundred-and-fifty-line one returns 350. Neither value is a failure by itself, since the configured policy is what decides which lengths this project accepts.

References

• Cites Pylint C0302 too-many-lines. Open reference
• Cites “A Philosophy of Software Design”, chapters 4 and 5