Six Practical Naming Principles Every Programmer Should Follow

Background

A common anecdote describes a graduate student who deliberately obfuscates his code by naming classes and members with meaningless sequences such as aa, ab, … bz. He keeps a separate notebook that maps each name to its meaning. When his laptop is lost, no one can understand the code, illustrating how poor naming makes debugging and maintenance virtually impossible.

Six Naming Principles (proposed by George)

Avoid figurative language. Use literal, domain‑specific terms instead of metaphors, similes, or literary expressions. A name should describe *what* the entity is, not *how* it feels.

Prefer concise terms. If a short word conveys the same meaning as a longer one, choose the short word. Long identifiers increase line length and visual noise.

Minimize phrase length. When possible, shorten multi‑word expressions. For example, use count instead of numberOfElements if the context is clear.

Use active voice. Prefer verbs that describe the action performed by a function or method. For instance, name a method sendRequest rather than requestSent.

Avoid foreign or academic jargon. Choose everyday language that most developers understand. Replace terms like utilize with use, or instantiate with create.

Break the rules when clarity demands it. If none of the above yields a clear, unambiguous name, prioritize the most direct expression even if it violates a previous rule.

Practical Implications

Applying these principles leads to code that is easier to read, debug, and maintain. Short, literal, active names reduce cognitive load, improve searchability, and facilitate collaboration across teams.