We Can Afford To Buy Vowels
TL;DR Programs must be written for people to read, and only incidentally for machines to execute —Harold Abelson
In the old days <eyeroll/>, we had 26 variables: the letters of the alphabet. The next leap in programming, we could add one digit after the letter. That was not good enough for development then, and it surely is not now
With no restriction on the length of names, the vestigial traditions of opaque naming cannot hide behind brevity or idiom, and certainly not consistency1. The only measure for names is their utility in communication
A line of code like r.Get(true)
is opaque. While IDEs can help decode what the r
and the true
mean, using descriptive names allows the code to speak for itself: orderReader.Get(CacheDataOk)
Multi-letter abbreviations harken back to Hungarian notation: abjad2 type names prefixed or suffixed to a (presumably) descriptive name (e.g. submitBtn). Or they presume screens are fixed at 80 x 40 characters (e.g. DTE for “Date”). While names might be too long3, unabbreviated names are easier and more accurate for humans to read; code readers should be free to focus on the why of the code, not the what does this mean‽ of the code
Good code reads like well-written prose —Grady Booch