> Good code doesn’t just solve a problem, it solves it in a way that’s readable and modular.
Strongly disagree.
There are plenty of cases where non-modular code is more readable and faster than modular code (littered, presumably, with invocations of modular logic).
There are also countless cases, particularly in low-level languages or languages with manual memory management, where the best solution -- or the correct solution -- is far from readable.
Readability is anyways in the eye of the beholder (My code is readable. Isn't yours?) and takes a back seat to formal requirements.
Just as a matter of personal style, I prefer long, well-organized functions that are minimally modular. In my experience, context changes -- file boundaries, new function contexts, etc -- are the single greatest source of complexity and bugs, once one has shipped a piece of code and needs to maintain it or build on it. Modular code, by multiplying those, tends to obscure complexity and augment organizational problems by making them harder to reason about and fix. Longer functions certainty feel less readable initially but I'd wager they produce better, clearer mental models, leading to better solutions.
I think the important concept that "readable and modular" is trying to get at is how easy is it to continue working on the code in future. There's definitely codebases that are easier to work on than others, even when the domain is the same.
I'd say that readability, which often boils down to consistency, and modularity are ways to do this, but they aren't the only ways. And as you say, sometimes there's a need for "unreadable" code, so not everything can be easy.
Strongly disagree.
There are plenty of cases where non-modular code is more readable and faster than modular code (littered, presumably, with invocations of modular logic).
There are also countless cases, particularly in low-level languages or languages with manual memory management, where the best solution -- or the correct solution -- is far from readable.
Readability is anyways in the eye of the beholder (My code is readable. Isn't yours?) and takes a back seat to formal requirements.
Just as a matter of personal style, I prefer long, well-organized functions that are minimally modular. In my experience, context changes -- file boundaries, new function contexts, etc -- are the single greatest source of complexity and bugs, once one has shipped a piece of code and needs to maintain it or build on it. Modular code, by multiplying those, tends to obscure complexity and augment organizational problems by making them harder to reason about and fix. Longer functions certainty feel less readable initially but I'd wager they produce better, clearer mental models, leading to better solutions.