Why we need a book about naming
A good name is like a good car. Is a race car a better car than a truck? Lot of trade-offs to make.<p>You want names to be short, so you easily write and read them. Especially if you use them a lot, it&#x27;s useful to use abbreviations, like x, e, i, z.<p>You also want names to be easy to understood, therefore, longer than few letters. So, &quot;count&quot; instead of &quot;cnt&quot; or &quot;c&quot;, in short, no abbreviations.<p>You want names not to clash. So every name should be a unique 64-character long identifier, as far as distant from anything else as possible. However, they should also be optimized for the tree search when using completion.<p>You want names to describe similar things with similar names. In particular, my pet peeve, how to name objects that are &quot;essentially the same thing&quot; but only different structure so I could better manipulate them, like converting list of tuples to a dictionary? From purely domain point of view, they should not even have different types! And did you know that every Monad is an Applicative?<p>Should the name reflect the result only or also the path that was taken to get to it - &quot;customerList&quot; or &quot;customerListFiltered&quot;? Or perhaps just &quot;list&quot;, because the function is not specific to customers. It&#x27;s local context versus global consistency.<p>There are minor problems as well. Underscore_case looks ugly, dash-case is mostly not supported, camelCase is just weird when you want to have anotherCamel (now strangely upper-cased), and CapitalCase looks ugly with acronyms. And should we put adjectives in front or at the back? And why are the elements of EMarble called RED, GREEN and BLUE?