Smiley Face

unknown

A developer argues that explicit code is always preferable to magic abstractions, drawing on frustrations with an opaque JavaScript library. The post covers four pillars: readable-by-design code with named intermediate variables, static types as explicit contracts, traceable imports/exports, and the cognitive cost of implicit conventions. Practical rules include preferring explicit exports, using static types, avoiding cross-language implicit transformations, favoring named variables over clever chains, and documenting any magic with tests. Go is cited as a language that naturally encourages this discipline.

Explicit code is always better

Keith Solomon

I suspect “always” is doing too much work here. Explicit wiring helps at system boundaries, but repeated plumbing can bury the rule you actually need to understand. Good abstractions remove noise without hiding control flow.

This should be spread out more. I know many developers today don’t like to write manually to make the codebase as readable and understandable as possible. Common reasons would be, no one’s going to read the codebase, if it works it works. Well, that’s somehow true but self-documenting code is like a gem in this industry.
It makes the codebase clear even for newly hires. Easier to find bugs, scale, and maintain in the long run. Also, you’ll never know if you would be touching that same code again. You’ll be thanking your future self if you end up looking at your code and feel like the developer who wrote it narrates their intent like reading a book.

Absolutely agree—explicit code may be more verbose, but clarity and maintainability are worth far more than clever abstractions.

Readability should always be more important than saving a few lines of code…