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 can 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

  1. emerson 

  2. abjad: a writing style omitting vowels (e.g. Semitic) 

  3. my coworkers won’t believe I said this 


Now read this

Don’t Worry About Anything, Just Call Us

Callbacks are great and always have been. Long ago, we didn’t know we were injecting control or inverting dependencies; we just used them. When closures appeared, I did not see a huge difference: a little state here, a little context... Continue →