Practical Naming Guidelines for Code: Principles, Rules, and Vocabulary

Naming in software development is a notoriously hard, counter‑intuitive task; experienced developers often struggle to choose clear, concise identifiers.

Key difficulties include information compression, future‑proofing, language proficiency, and poor design, making naming a test of design quality.

The article proposes practical, experience‑based guidelines: names should be precise, readable ( [Object] [Does...] ), avoid ambiguous abbreviations, and use a single‑concept taxonomy. Public APIs favor full nouns, methods use verb‑noun forms, and getters omit the “get” prefix.

Common abbreviations accepted are config → config , id , spec , stats , db , re/regex/regexp ; unapproved ones include req , resp , svr , etc.

Language‑specific advice covers Java (no “I” prefix for interfaces, Impl suffix for implementations), C++ (use Impl , Base ), and Go (avoid interface/struct suffixes, no abstract classes).

Design‑pattern naming follows GoF conventions: factories, builders, adapters, decorators, proxies, iterators, observers, strategies, commands, etc., each with recommended verb forms.

Additional sections discuss naming for classes, methods, verbs (create, add, update, delete, find, copy, etc.), lifecycle methods (init, start, pause, stop, destroy), and metadata (options, config, properties).

Example of bad versus good naming for avoiding numeric shortcuts:

func foo2Bar(f *Foo) *Bar   // BAD
func fooToBar(f *Foo) *Bar // GOOD
func to(f *Foo) *Bar       // Good if not ambiguous.