"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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.