The second episode talks about how to name variable, classes and function. Most of the ideas are coming from Tim Ottinger’s Rules for Variable and Class Naming paper.
- Reveal the intent
- variable should described itself.
- Described the problem
- If you need to read the code to understand the name, then the name failed its purpose
- Name is a tool to communicate intent and this is its first priority when naming
- Avoid disinformation
- Name should say what it means and mean what it says
- Pronounceable name
- Name that can be pronounced, can be communicate effectively. On the other hand, name can’t be pronounced, cannot be communicate effectively.
- Avoid encoding
- Using encoding distract the communication of the name and obscure the readability of the code.
- Part of speech
- Variable and class should be noun or noun phrase (e.g. date, account, address … etc.)
- Method and function should be verb (e.g. setDate, getName, changeNameTo … etc.)
- Boolean variable and function that returns a boolean should be a predicate (e.g. isSet, isLate … etc.)
- Enum should be adjectives.
- Ignore noise word like manager, data, info, processor that does not add meaning to the name.
- Use get for accessor (getName … etc)
- Scope length rule
- The longer the scope of a variable, the longer the name should be
- It is ok to use one alphabet to represent a variable if the scope is very short (e.g. i for index in a compact for-loop)
- The longer the scope of a function or a class, the shorter the name should be
- Public function and classes should have short name because it will be call from many places and it should be convenience to do so.
- Derived class often add adjective in front of parent class and get longer (e.g. Account, savingAccount … etc.)