• Clean codes are elegant and efficient.
  • Straightforward, minimal dependencies, articulated error handling, optimal performance, does one thing well.
• Boy Scout Rule: Leave the campground cleaner than you found it.

Meaningful names

• Use intention-revealing names
  • Answers all big questions; no comment required
• Avoid disinformation
  • Like single-letter names
• Make meaningful distinctions
  • Not sufficient to add numbers, noise words or prefix conventions (“a”, “the”, etc) to distinguish two similar variables
    • e.g., list_1, list_2; product_info, product_data
• Use pronounceable names
  • Avoid names like genymdhms
• Use searchable names
  • MAX_CLASSES_PER_STUDENT instead of 7.
  • Single-letter names may be fine as a local variable inside short methods.
• Avoid encodings
  • Avoid encode type or scope information into names
• No member prefixes like m_address
• Interfaces and implementations
  • Prefer to leave interfaces unadorned, ShapeFactory instead of IShapeFactory. Users don’t need to know we are handling them an interface. Implementations can be encoded like ShapeFactoryImpl.
  • Avoid mental mapping
    • Readers shouldn’t have to mentally translated a name into other name they already know, like t for time.
• Class names
  • Should be noun or noun phrases like Customer, Account, AddressParser.
  • Choose a more descriptive names, avoid Manager, Processor Data or Info.
• Method names
  • Should be verb or verb phrases.
  • Try use get, set prefixes.
  • When the constructors are overloaded, prefer static factory methods with names that describe the arguments.
    • e.g., Complex.FromRealNumber(23.0) is better than new Complex(23.0).
    • Consider making corrsponding constructors private.
• Don’t be cute
  • Say what you mean. Avoid using slangs. Just DeleteItems instead of HolyHandGrenade.
• Pick one word per concept
  • and stick with it. get, fetch, retrieve; controller, manager, driver etc.
• Use solution domain names
  • CS terms, algorithm names etc. Visitor, Queue
• Using problem domain names
• Add meaningful context
  • Use addrState to note the state is for address. Using an Address class is even better.
• Don’t add gratuitous context
  • Don’t use the same prefix for many methods and classes. Shorter names are generally better. Add no more context to a name than is necessary.

Functions

• Small
  • Functions should hardly ever be 20 lines long.
  • The indent level of a function should not be greater than one or two.
• Do one thing
  • Do it well and do it only.
  • Sections within functions, a clear indication that a function is doing more than one thing.
• One level of abstraction per function
• The stepdown rule, reading code from top to bottom
  • We want the code to read like a top-down narrative.
  • Every function to be followed by those at the next level of abstractions.