Exceptional Naming. When code throws or catches an… | by Kevlin Henney | May, 2021 | Medium
One of the hardest things in software development is naming. Naming of products, of paradigms and of parts of your code. The reason naming is both hard and important is because it is an act of communication; without good names your code might as well be written in, well, code. A name is not simply a label: it informs and guides the reader’s mental model. Names can change the way the reader thinks. A good name is a sharing of minds; a poor name is a missed opportunity to learn and say what we mean.
We oft en adopt conventions to make some aspects of naming easier. Such consistency can be a good thing, but not all practices that are consistent are necessarily good. Having a common vocabulary of concepts is useful across a codebase, but the concepts named should qualify as useful information — consistent noise is just noise.
Homeopathic naming is one of the commonest habits programmers can fall into without realising: making names longer by adding more words with the goal of adding more meaning to code, but in practice diluting the meaning with every Factory/Manager/Object/Controller/Value/Service/… added. Diluting things dilutes them; it does not make them more potent. Affixing Lego-brick parts to an identifier does not amplify or enhance its meaning, and often serves to highlight there may have been little meaning there in the first place. A naming convention should not be used to prop up weak names. If a name doesn’t communicate well, we need to see that clearly so we can address it rather than smothering it, hiding it behind a wall of Lego.
