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.
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.