Naming as Design

Every name is a compression of a concept. When the compression works, the reader understands the concept without decompressing it. They see calculateShippingRate and they know, without reading the method body, that it takes a shipment and returns a rate. They see warehouseSlot and they know it represents a physical storage location. The name replaces the comment. The name replaces the documentation. The name replaces the meeting where someone explains what this class does.

When the compression fails, the name adds cognitive load instead of removing it. The reader sees processData and must open the method to learn what it does. They see result and must trace its assignments to understand what it holds. They see ShipmentManager and must read the class to discover it handles tracking, billing, and carrier integration simultaneously.

A bad name is not a cosmetic issue. It is a failure of design made visible at the surface. If a method resists a clear name, the method is doing too many things. If a class resists a clear name, the class spans too many responsibilities. The naming struggle is diagnostic information. Ignoring it and settling for processData is like ignoring a check engine light because the car still moves.

This diagram shows the naming clarity spectrum applied to variables in the logistics codebase. On the left, names like d, temp, and data force the reader to hold the full context in memory to understand what they represent. On the right, names like shipmentWeight, carrierBaseRate, and deliveryDeadline communicate their purpose without any surrounding context. The middle zone, names like result, info, and status, are context-dependent: sometimes clear enough, often not. Every name pushed from left to center, or from center to right, removes one chunk from the reader’s working memory.