🤘 clean code

“Clean code doesn’t matter if it’s not readable” and “readability > efficiency” seems to be the trendy programming argument to make lately.

This is pretty clearly a false dichotomy.

First of all, readability can be improved without changing anything about the logic itself. Naming conventions, file and directory arrangement, syntax rules, and even tests all enhance readability without changing what the program actually does.

Second, clean code does not mean “clever.” Good code is almost always more simple, not more convoluted. It’s easy to look at an overengineered program and mistake complexity for quality. Complexity is bad. The purpose of (most) code is to reduce complexity and improve readability for human readers - who are fluent in the language.

(Fluency is a requirement here, and I think this is why the false dichotomy exists. Code isn’t going to be readable if you can’t read the code, but don’t mistake a reader’s illiteracy as “bad” code).

Third, logical efficiency is not in and of itself less readable. An abstraction or modularization that reduces the absolute complexity of the program should make the program more readable, not less. That being said, sometimes abstraction means bringing threads of logic together and then splitting them apart again in ways that aren’t immediately obvious. This is where conventions, documentation and tests have to do the heavy lifting of readability. But this should be the very intentional exception - the rule should be simple, easily traced logic flows.

Code is meant to be read. That’s the whole point. Conventions and best practices have developed over time to enhance readability. So the argument that these very conventions are somehow antithetical to readability is flawed from the start.