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


  1. emerson 

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

  3. my coworkers won’t believe I said this 

 
0
Kudos
 
0
Kudos

Now read this

The Futures of Python

Futures defer execution of code. They can allow code to wait for external resources like file reads, network calls, and database access, and then automatically continue without stopping every other operation. They allow the definition... Continue →