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 consistency¹. 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: abjad² 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 long³, 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