Clean Code: Names

This is a quick review of the main points in the “Clean Code” chapter on names. Clean Code is available as a video or book.

Communication

  • Communication is important when naming variables, methods and classes
  • Names should not require comments to explain their intent
  • Collaborators should not need to read a lot of code to understand a name’s meaning
  • What a name says it is/does should reflect what it actually is/does
  • Make names readable/pronounceable

Parts of speech

The idea is that code should read like “well written prose”, using the appropriate parts of speech.

  • Booleans should be predicates (e.g. isEmpty)
  • Classes and variables should be nouns (e.g. BankAccount, savings)
  • Methods should be verbs (e.g. getName()), unless the method returns a boolean, in which case it should be a predicate
  • Enums should be adjectives (e.g. GREEN)

Scope Length Rule

  • Variables: longer scope, longer descriptive names: shorter scope, shorter names
  • Functions & Classes: longer scope/public/called often: short, convenient names
    shorter scope/private/infrequently called: long, detailed names
  • Derived/Sub- classes: longer names as they become more descriptive/less abstract