Key 1. Fundamental Theorem of Readability.
Code should be written to minimize the time it would take for someone else to understand it (Time-Till-Understanding metric).
Key 2. Packing Information into Names. Pack information into your names:
a. Choose Specific Words;
b. Finding More 'Colorful' Words, (Word Alternatives: send - deliver, dispatch, announce, distribute, route; find - search, extract, locate, recover; start - launch, create, begin, open; make - create, set up, build, generate, compose, add, new) ItТs better to be clear and precise than to be cute;
c. Avoid Generic Names Like tmp and retval;
d. Prefer Concrete Names over Abstract Names;
e. Attaching Extra Information to a Name;
f. Shorter Names Are Okay for Shorter Scope;
g. Use Name Formatting to Convey Meaning;
Key 3. Actively scrutinize your names by asking yourself, 'What other meanings could someone interpret from this name?'
Before you decide on a name, play devil's advocate and imagine how your name might be misunderstood. The best names are resistant to misinterpretation.
a. When it comes to defining an upper or lower limit for a value, max_ and min_ are good prefixes to use.
b. For inclusive ranges, first and last are good. For inclusive/exclusive ranges, begin and end are best because theyТre the most idiomatic.
c. When naming a boolean, use words like is and has to make it clear that itТs a boolean. Avoid negated terms (e.g., disable_ssl).
d. Beware of usersТ expectations about certain words. For example, users may expect get() or size() to be lightweight methods.
