I agree with the author of the post saying that naming is poorly understood. That isn't to say that names are poor, it's just that the principles and importance

I agree with the author of the post saying that naming is poorly understood. That isn't to say that names are poor, it's just that the principles and importance of names is often not understood. What's the difference between a user-facing mass-market brand name versus package or component names? Why can I happily talk to my team about Drupal and everyone from the PM down to the intern are on board, but mention it to even the more savvy of end users and they glaze over? Why can't I just give a list of packages from the apt repository to my father and expect him to crack on with it in the same way I would if I put him in front of the Apple App store or Play store? I'm fairly sure this book is going to be about naming things within codebases or within the technical community, however I still find myself disagreeing with his list of principles in the next page over. > 1. Consistency - Each concept should be represented by a single, unique name. Agree and disagree. I agree that the same concept in the same context with the same audience will need a consistent name so that there is no confusion, but names are used to convey extra bits of information. Consider "headache tablet" vs "Paracetamol" vs "N-acetyl-para-aminophenol". Different audiences, different needs, different information being conveyed. Arguably the same component for a different concept, but even so it breaks the notion of consistency. In Mathematics we use different notation for the same concepts sometimes in order for our ideas to be expressed more succinctly or for our workings/thinking to be clearer. The same is true in tech. The secret isn't to name sparingly, it is to name well. > 2. Understandability - A name should describe the concept it represents. This is good in principle, but one concept could have many applications. I think sometimes we are limited in how we think about things merely by how they're named. As noted above, names can have certain assumptions baked into them which, while subtle, can block other forms of thinking. Even taking something like 'Object' from OOP can be misleading. You don't always have an object for a solid thing, a well-defined business concept/entity etc. The object itself only makes sense to those working at the same level of abstraction as the code which may only be the developers of that specific application. The term 'object' itself, then, becomes only meaningful as a programming concept, it doesn't actually describe what the thing is other than "a collection of stuff with things you can do to it attached". > 3. Specificity - A name shouldn’t be overly vague or overly specific. I've touched on this above, but in this specific case we're aiming for a middle of the road please-everyone-but-no-one approach where the name is neither descriptive or catchy enough for people to remember, specific enough for people to find useful in practice or intuitive enough for people to build up mental models around. > 4. Brevity - A name should be neither overly short nor overly long. If you make it too short then everyone will only be able to name your concept with qualifiers. If you make it too long then people will abbreviate so that it is no longer unique. If you have multiple names for multiple purposes you break the 'single consistent' name principle above. Long names have uses. Short names have uses too. > 5. Searchability - A name should be easily found across code, documentation, and other resources. I like this. I think every project/concept needs to have at least one name that is specific and unique enough that you can use it to find exactly what you need to. I do, however, think that the name is only part of this. You also need unique combinations of names/concepts/verbs in order for you to find the specific thing that you need. > 6. Pronounceability - A name should be easy to use in common speech. Again, depends on the purpose. (pentacyclo[4.4.0.02,5.03,8.04,7]decane) is technically pronounceable but cumbersome in casual conversation. It is also unique and descriptive. Everything has its place. > 7. Austerity - A name should not be clever or rely on temporary concepts. Sometimes these are good, sometimes they turn sour. I agree that the Gnu Image Manipulation Program should have a more savoury name if it genuinely wants to serve the needs of a mass audience. I also like that `less` is `more` - a joke that means that the `less` command doesn't really describe its function or give the user any clue about its place in the ecosystem without using it or looking it up. So yes, I think ultimately some of these are "no, that won't work" and others are "it depends". A nice, albeit somewhat cryptic, explanation of names is discussed at various points in Patrick Rothfuss' Kingkiller Chronicle. He also has some interesting blogs on the topic of naming if you can hunt them down.