Readability is inherently a subjective thing, and it’s therefore hard to put a solid definition on exactly what it means. The essence of readability is ensuring that engineers can quickly and accurately understand what some code does. Actually achieving this often requires being empathetic and trying to imagine how things might be confusing or open to misinterpretation when seen from someone else’s point of view.
This chapter should provide a solid grounding in some of the most common and effective techniques for making code more readable. It’s worth remembering, though, that each real-life scenario is different and has its own set of considerations, so using common sense and applying good judgment are both essential.
Names are needed to uniquely identify things, but they often also provide a brief summary of what the thing is. The word toaster uniquely identifies an appliance in your kitchen, but it also gives a massive hint as to what it does: it toasts things. If we, instead, insisted on referring to a toaster as “object A,” then it would be quite easy to forget what exactly “object A” is and what it does.