Skip to content
aipatterns.dev

Refactoring techniqueComposing Methods

Inline Method

Replace calls to a function whose body is as clear as its name with the body itself, then delete the function.

Also known as
Inline Function

Problem

A function adds a name but no meaning. Its body is one obvious line, or it only forwards to another call. Readers jump to the definition and find nothing they could not have read in place.

Solution

Put the body at each call site and delete the function. Do this also as a reset: inline a tangle of badly split helpers back into one function, then extract them again along better lines.

Before

TypeScript
class SessionPolicy {
  constructor(private readonly maxIdleMinutes: number) {}

  isExpired(session: Session, now: Date): boolean {
    return this.idleMinutes(session, now) > this.limit();
  }

  private idleMinutes(session: Session, now: Date): number {
    return minutesBetween(session.lastSeenAt, now);
  }

  private limit(): number {
    return this.maxIdleMinutes;
  }
}

After

TypeScript
class SessionPolicy {
  constructor(private readonly maxIdleMinutes: number) {}

  isExpired(session: Session, now: Date): boolean {
    return minutesBetween(session.lastSeenAt, now) > this.maxIdleMinutes;
  }
}

Why

  • Fewer hops to understand the code. The condition is visible in one line.
  • Removes indirection left over from earlier refactorings or from speculative "maybe we'll override this" hooks.
  • Inlining a cluster of small, poorly named helpers is often the fastest route to re-extracting good ones.

Steps

  1. Confirm the function is not polymorphic: no subclass overrides it and no interface requires it. If one does, stop.
  2. Find every call site. Include reflection, string-based dispatch, templates and tests.
  3. Replace one call with the body, substituting arguments for parameters. Run the tests.
  4. Repeat for each remaining call site.
  5. Delete the function. Run the tests again.

Watch out

  • Don't inline a method that subclasses override or that is part of a public API. Callers outside your codebase break.
  • Don't inline when the body is long or used in many places. You trade one name for duplicated code; that is the Duplicate Code smell.
  • If arguments have side effects or are expensive, substituting them into the body more than once changes behavior. Assign them to a local first.
  • Recursive functions and those with several return statements need care; turning them into inline code may require restructuring.
  • The inverse is Extract Method. Extract when the body is less clear than a name would be.

Agent checklist

  • No override, interface contract or external caller depends on the method.
  • All call sites were found, including dynamic and test references.
  • Arguments with side effects are evaluated exactly once after inlining.
  • The inlined code is no harder to read than the call was.
  • The method is deleted and tests pass.

Treats these smells

See also

Original writing and examples. Topic coverage follows Refactoring.Guru, which explains this topic with its own illustrations.