node created 2019/09/29
I make a statement. Then another. Soon, more follow; truncated by pauses, commas, contemplative line breaks. The flow is shallow, stagnated. The words stop as quickly as they start. Another sentence. They are interminable, needlessly pithy reminders of a point I'm trying to bore into your skull. They are obtrusive. Some time later - though not so much later, in this instance - I break my cadence with a qualification blocked in hyphens. It is expository, important, essential to the rhythm of the piece. You can tell that this is intentional. Another sentence. Then another. This one, slightly longer, though not much. My points are considered; important. Take heed of this gravitas.
A few Hackernews suggest that AMP's feature set can be replicated with a "stop shoving every fucking possible line of javascript into every single pageload" approach, but they are quickly chloroformed and edited out of past Christmas photos.
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"
The great enemy of clear language is insincerity. When there is a gap between one’s real and one’s declared aims, one turns as it were instinctively to long words and exhausted idioms, like a cuttlefish spurting out ink.