When Naming Is Hard

Chapter 3 covered names that are bad because the developer settled for a vague word when a precise word was available. This chapter covers a different problem: names that are bad because no precise word exists. The method does three things, so no single verb describes it. The class spans two domains, so no single noun contains it. The parameter represents a concept that has no name because the concept should not exist.

When naming is hard, the instinct is to blame the vocabulary. The developer thinks harder, considers synonyms, asks a colleague. This is the wrong response. When naming is genuinely hard, the difficulty is diagnostic. It points at a design problem. The code is doing something that resists concise description because it is doing too much, or combining things that should be separate, or encoding a decision that should be made elsewhere.

This chapter uses naming resistance as a refactoring tool. When a name is hard, stop trying to name the code. Fix the code until the name is obvious.

This diagram maps common naming difficulties to their underlying design problems. A method that resists a single verb is doing multiple things. A class that resists a single noun spans multiple responsibilities. A parameter that resists a descriptive name represents a collapsed abstraction. The arrow from naming difficulty to design fix is the central technique of this chapter: use the struggle to name as a compass pointing at the structural problem.