Long Method

A method that has grown too large.

“The longer a procedure is, the more difficult it is to understand.” – Fowler & Beck

If you need to scroll to read a single method, it’s probably too long.

Signs of Use (Symptoms)

  • Method exceeds 10-20 lines.
  • Multiple levels of abstraction within one method.
  • Comments dividing sections inside the method (“// Step 1”, “// Step 2”).

Why it is bad (Consequences)

  • Readability: Hard to understand what it does at a glance.
  • Testability: Difficult to isolate and unit test.
  • Reusability: Embedded logic cannot be reused elsewhere.

Why it happens (Root Cause)

Adding “just one more line” is easier than creating a new method. Over time, methods grow organically.

When it might be okay (Exceptions)

  • Boilerplate-heavy frameworks where extraction creates more complexity.
  • Generated code.

Explanation

Problem

You start with a simple function. Requirements change, new cases appear, and you keep adding code.

The Flaw

A long method hides intentions. You can’t tell what it does without reading every line.

Real world analogy

A restaurant menu with 200 items. It’s overwhelming. You’d rather have a curated menu of 10 excellent dishes.

Refactoring Solution

  • Extract Method: Break into smaller, named helper functions.
  • Replace Temp with Query: If temps are cluttering the method.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • Fast to add code
  • Everything in one place
    		•
  • Hard to read
  • Hard to test
  • Duplication
    		•

    Comparison

    • Related Antipatterns: Large Class.
    • Related Principles: Violates SRP.

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)

    PHP

    Bad (The Antipattern)

    Good (The Fix)