Extra#5199 <
> #5183
All naming decisions have several constraints in common. You want names that are as short as possible, so they are easy to type, format, and say. At the same time, you want to convey as much information as possible in each name, so readers will not have to carry as much knowledge in their heads. You want names that are familiar, to take advantage of knowledge readers already have via metaphor or analogy. However, you want names that are unique, so that others who are also choosing names will not accidentally choose names that interfere with yours. The first rule I follow is no abbreviations. Abbreviations optimize typing (a 10–100 times in 20 years task) over reading (a 1000–10000 times in 20 years task). Abbreviations make the interpretation of a name a two step process—what do the letters stand for and then what do those words mean. The class and method naming patterns here will produce names that you should never have to abbreviate. Naming the root class of a large hierarchy is a momentous occasion. People will be using the words you choose in their conversation for the next 20 years. You want to be sure you do it right. Unfortunately, many people get all formal when they go to name a superclass. Just calling it what it is isn’t enough. They have to tack on a flowery, computer science-y, impressive sounding, but ultimately meaningless word, like Object, Thing, Component, Part, Manager, Entity, or Item. You’re creating a vocabulary, not writing a program. Be a poet for a moment. The simple, the punchy, the easily remembered will be far more effective in the long run than some long name that says it all, but in such a way that no one wants to say it at all."Smalltalk Best Practice Patterns"