Method Length Guidelines
debt(d5/e3/b3/t5)
Closest to 'specialist tool catches it' (d5), because detection_hints lists phpmd, phpcs, phploc, and sonarqube — all specialist static analysis tools that must be explicitly configured and run; the violation is not caught by the compiler or a default linter, but these tools make it reliably detectable when used.
Closest to 'simple parameterised fix' (e3), because the quick_fix describes identifying a cohesive block and extracting it into a private method — a localised refactor within one component/file rather than a one-line patch or cross-cutting change. Common mistakes like inlining instead of extracting confirm the fix requires deliberate, targeted restructuring.
Closest to 'localised tax' (b3), because method length is a per-method concern within individual classes. While it applies across all contexts (web, cli, queue-worker), each instance of a long method is an isolated structural debt that burdens maintainers of that specific class rather than imposing a gravitational pull on the entire codebase.
Closest to 'notable trap' (t5), because the misconception field explicitly identifies the canonical wrong belief — that method length limits are arbitrary rules with no real benefit. Competent developers who haven't internalised clean-code principles often resist extraction, inline complexity rather than extracting it, or use comments as section dividers instead of extracting methods — documented gotchas that most developers eventually learn.
Also Known As
TL;DR
Explanation
Long methods are one of the oldest and most reliable code smells. Martin Fowler recommends that any method longer than five lines is worth scrutinising; practically, methods over 20 lines should be refactored. Long methods almost always have multiple responsibilities that can be extracted into well-named helper methods. Each extracted method should be small enough to have a name that fully describes its purpose — if you cannot name it clearly, it may still be doing too much. Cyclomatic complexity is often more meaningful than raw line count — a 30-line linear method may be fine; a 10-line method with 6 branches is complex.
Common Misconception
Why It Matters
Common Mistakes
- Not extracting private methods when a function exceeds 20-30 lines.
- Comments used to separate 'sections' of a long method — each section is a candidate for extraction.
- Test methods as long as the code they test — long test methods indicate the production code does too much.
- Reducing method length by inlining logic rather than extracting it — moves complexity, doesn't reduce it.
Code Examples
// 80-line method doing too many things
public function processOrder($cart, $user, $payment) {
// 15 lines: validate cart
// 20 lines: apply discounts
// 15 lines: process payment
// 20 lines: send notifications
// 10 lines: log audit trail
}// Extract each concern into its own method
public function processOrder(Cart $cart, User $user, PaymentMethod $payment): Order {
$validated = $this->validateCart($cart);
$discounted = $this->applyDiscounts($validated, $user);
$charged = $this->processPayment($discounted, $payment);
$this->notifyUser($charged, $user);
$this->logAudit($charged, $user);
return $charged;
}
// Each extracted method: 5-15 lines, one clear purpose
// Guideline: if a method needs a comment to explain sections, extract those sections