ALL-FUNC0003 · class_owned_module_helper

Detect a module helper used exclusively by one class method.

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

Definition

Inspect undecorated module functions with one leading underscore and at least minimum_lines executable lines. Report only when the complete analyzed source set contains exactly one static load of the helper, that load is a direct call in a method body, and the method is defined directly on one class. This proves a narrow class-owned behavior candidate without rejecting private functional decomposition generally.

Evidence

Each finding cites the helper definition, owning class, method, and sole direct call. The review repair moves the helper before its sole calling method and qualifies that call through the owning class. The provider proves that no other static reference exists first.

Exceptions

Module-private helpers called by module functions are permitted. Additional references, multiple callers, callback capture, attribute access, cross-file uses, decorators, module dunder hooks, nested functions, and uncertain ownership fail closed without a finding. The one-line helper rule separately owns helpers below the default two-line floor. ignore_names retains a helper whose module-level position is deliberate, and minimum_lines is the floor below which the one-line helper rule owns the candidate instead.

Examples

Bad

`_parse_response` has two implementation lines and its only project reference is the direct
call `ApiClient.request -> _parse_response(...)`. It is a candidate for `ApiClient` ownership.

Good

_parse_response called by a module function remains valid. Helpers shared by several methods, passed as callbacks, or referenced outside the defining file are not assigned to one class.

References

• Cites “PEP 8, Style Guide for Python Code”, Public and Internal Interfaces. Open reference
• Cites “A Philosophy of Software Design”, chapters 4 and 5
• Cites “Agile Software Development”, single responsibility principle