TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2. Meaningful Names

책에서 기억하고 싶은 내용을 써보세요.

Use Intention-Revealing Names (p.18)

• If a name requires a comment, then the name does not reveal its intent.

• int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

• The problem isn't the simplicity of the code but the implicity of the code (to coin a phrase): the degree to which the context is not explicit in the code itself.

Avoid Disinformation (p.19)

• Programmers must avoid leaving false clues that obscure the meaning of code.

• Do not refer to a grouping of accounts as an accountList unless it's actually a List. If the container holding the accounts is not actually a List, it may lead to false conclusion. So accountGroup or bunchOfAccounts or just plain accounts would be better.

Make Meaningful Distinctions (p.20)

• Number-series naming (a1, a2, ..., aN) is the opposite of intentional naming.

• Noise words are another meaningless distinction. Info and Data are indistinct noise words like a, an, and the.

• Distinguish names in such a way that reader knows the differences offer.

Use Pronounceable Names (p.21)

• If you can't pronounce it, you can't discuss it without sounding like an idiot.

Use Searchable Names (p.22)

• Single-letter names and numeric constants have a particular problem in that they are not easy to locate across a body of text.

• My personal preference is that single-letter names can ONLY be used as local variables inside short methods, for example sum in the next code.
  int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
  int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
  int realTaskWeeks = (realDays / WORK_DAYS_PER_WEEK);
  sum += realTaskWeeks;
  }

Avoid Encodings (p.23)

• Encoding type or scope information into names simply adds an extra burden of deciphering.

Hungarian Notation (p.23)

Member Prefixes (p.24)

Interfaces and Implementations (p.24)

Avoid Mental Mapping (p.25)

• Readers shouldn't have to mentally translate your names into other names they already know.

• One difference between a smart programmer and a professional programmer is that the professional understand that clarity is king.

Class Names (p.25)

• Classes and objects should have noun or noun phrase names like Customer, Wikipage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.

• Method names (p.25)

• Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is according to the javabean standard.
  string name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted())...

Don't Be Cute (p.26)

• Say what you mean. Mean what you say.

• Cuteness in code often appears in the form of colloquialisms or slang.

Pick One Word per Concept (p.26)

• Pick one word for the abstract concept and stick with it. For instance, it's confusing to have fetch, retrieve, and get as equivalent methods of different classes.

Don't Pun (p.26)

• Avoid using the same word for two purposes. Using the same term for two different ideas is essentially a pun.

• Our goal, as authors, is to make our code as easy as possible to understand.

Use Solution Domain Names (p.27)

• Remember that the people who read your code will be programmers. So go ahead and use computer science (CS) terms, algorithm names, pattern names, math terms, and so forth.

Use Problem Domain Names (p.27)

• Separating solution and problem domain concepts is part of the job of a good programmer and designer.

Add Meaningful Context (p.27)

• You need to place names in context for your reader by enclosing them in well-names classes, functions, or namespaces. When all else fails, then prefixing the name may be necessary as a last resort.
  firstName, lastName, street, houseNumber, city, state, zipcode.
  addrFirstName, addrLastName, addrState, and so on.
  Better to use class Address.

Don't Add Gratuitous Context (p.29)

• Shorter names are generally better than longer ones, so long as they are clear. Add no more context to a name than is necessary.

Final Words (p.30)

• The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• It was pretty a useful chapter with practical example. From those examples, I also realized that I have been using quite a lot of them. Time to stop doing that and move on to be a better programmer!

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• Solution domain names vs Problem domain names (p.27)