"Good code" or "Bad code" isn't a practical or useful way of thinking about it, because it's not just about the code, it's also about the situation and goals.
A better way of thinking of it is "fitness to purpose": does this code fulfill your goals?
You might need to maintain the code, which requires one set of criteria...
or you might run it once and throw it away.
Those two situations result into two different kinds of fitness to purpose, two different ways of judging your code.
It's the other way around: "quality" has no meaning except in regard to your goals.
If maintaining something is a goal, then your code needs to meet certain properties, which you then call "quality". But "quality" is not a property of the code itself, separate from its goals: it only makes sense in a specific situation.
Maybe I am a bit biased because my background is in enterprise software so code is maintained across dozens, if not hundreds, of developers and even small changes can persist for years. Having well-defined code quality standards that are shared across teams is imperative.
"Good code" or "Bad code" isn't a practical or useful way of thinking about it, because it's not just about the code, it's also about the situation and goals.
A better way of thinking of it is "fitness to purpose": does this code fulfill your goals?
Those two situations result into two different kinds of fitness to purpose, two different ways of judging your code.
Longer version: codewithoutrules.com/2017/11/07/no...
I consider anything that is going to be maintained for any significant amount of time to require some degree of quality.
It's the other way around: "quality" has no meaning except in regard to your goals.
If maintaining something is a goal, then your code needs to meet certain properties, which you then call "quality". But "quality" is not a property of the code itself, separate from its goals: it only makes sense in a specific situation.
Maybe I am a bit biased because my background is in enterprise software so code is maintained across dozens, if not hundreds, of developers and even small changes can persist for years. Having well-defined code quality standards that are shared across teams is imperative.
Right, and that's a specific situation with specific needs. Not saying you don't need those standards, just saying those standards are situational.