reviewing-readability

Code readability assessment applies Miller's Law thresholds to measure cognitive load. Evaluate naming clarity, control flow simplicity, and nesting depth against practical limits: parameters ≤5, methods ≤7, branches ≤5, function length ≤15 lines, nesting ≤3. This identifies where refactoring reduces mental overhead during code review.

Miller's Law establishes cognitive limits for holding information. Applied to code: functions should have ≤5 parameters, ≤7 methods per class, ≤5 branches per function, ≤15 lines per function, and ≤3 levels of nesting. These thresholds keep code within human working memory capacity.

Refactoring for readability involves optimizing naming conventions, simplifying control flow, and reducing nesting depth. Apply before/after guidance grounded in The Art of Readable Code principles: use descriptive names, flatten nested logic, extract long functions into smaller units, and justify complexity where limits are exceeded.

Readability assessment fits code reviews, refactoring initiatives, and architecture design decisions. Use it when cognitive load becomes a bottleneck—functions exceed complexity limits, naming obscures intent, or nested control flow impairs maintainability. Early application prevents technical debt accumulation.

Readability depends on how quickly developers understand intent without excessive cognitive effort. Clear naming eliminates ambiguity, simple control flow reduces branching confusion, and shallow nesting prevents stack-overflow of logical context. These align directly with Miller's Law constraints on working memory.

Yes. Readability evaluation applies language-agnostic principles—parameter counts, nesting depth, function length, and branch complexity—across any codebase. Style variations matter less than consistency with cognitive limits and comment strategy improvements tailored to your team's conventions.