A nice reminder that skill and raw brainpower are two different things, and the latter can retard development of the former. I worked with many pieces of code written by one particular coworker of mine who was way too smart for his own good. His code was littered with little formulae like that, repeated again and again throughout a file, and to him it was obvious at a glance what they meant. It was also easy for him to scan through his code and find errors in these expressions, as easy as it is for you or me to see that "(matthes-js2-line-ending ..." contains a typo. I have no idea how he coped with finding and changing every instance of a formula that needed to be changed. For me it was a slog every time I had to read, change, or debug his code.
P.S. The most frequent and flagrant was calculating array indices into multi-dimensional arrays in C++. It's so easy to write a simple class that lets you do this:
By leaving out the definition of that long function name you mask the increased cognitive load of your change. If you include the definition of your new function it doesn't look like an improvement anymore.
We've also left out the new code that also has to match things against js2 line endings.
That said, this does require some taste. It is horrible to spread a single logical operation across multiple functions, classes, and files just for the sake of "object orientation" or "self documentation", but judicious application of bottom-up FP really helps code size and readability.
The Lisp function Yegge gives, is horrible in that aspect. for example this piece of code:
should really be more like No matter "how good you are" code reading is faster if what you read matches with what you're doing in English.