Can you expand on what you mean by "something that makes people complain about its quality?"
Also, my point is not that maintainability isn't important, only that it's important in a specific context - the context where it needs to be maintained. We make our code maintainable because we think it will need to be maintained, and 99% of the time that's a good thing. The point that I'm making is that we should make these tradeoffs thoughtfully, not that we shouldn't make tradeoffs at all.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
That's true, but the cases where we think it doesn't need to be maintained it will probably end up being maintained - or it's some kind of throwaway application for a one-off job.
The thing is, if you say you can write "bad" code for things you don't care about, and it's ok, why would you? You're essentially practising two different styles of coding for the sake of a short-term win, and that's probably more brainworking than if you wrote it all the same in the first place.
I think we're arguing different things. I'm not saying it's all cool to write "bad" code. I'm saying, what is the definition of "bad?" Why is writing code with this heuristic better than another heuristic? What implicit tradeoffs are we making when choosing one set of properties over another?
Personally I try to write code that is testable, maintainable (via composition) and with plenty of descriptive comments, because those are the things that I have chosen to care about. But when coming into someone else's codebase, it's not helpful to say "this is low quality." That word is so vague that it loses all meaning. The code has a certain set of properties, like testability or complexity, and when talking about improving it we need to be precise in our language or we're just saying "this is bad, you're bad, I know better than you."
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can you expand on what you mean by "something that makes people complain about its quality?"
Also, my point is not that maintainability isn't important, only that it's important in a specific context - the context where it needs to be maintained. We make our code maintainable because we think it will need to be maintained, and 99% of the time that's a good thing. The point that I'm making is that we should make these tradeoffs thoughtfully, not that we shouldn't make tradeoffs at all.
That's true, but the cases where we think it doesn't need to be maintained it will probably end up being maintained - or it's some kind of throwaway application for a one-off job.
The thing is, if you say you can write "bad" code for things you don't care about, and it's ok, why would you? You're essentially practising two different styles of coding for the sake of a short-term win, and that's probably more brainworking than if you wrote it all the same in the first place.
I think we're arguing different things. I'm not saying it's all cool to write "bad" code. I'm saying, what is the definition of "bad?" Why is writing code with this heuristic better than another heuristic? What implicit tradeoffs are we making when choosing one set of properties over another?
Personally I try to write code that is testable, maintainable (via composition) and with plenty of descriptive comments, because those are the things that I have chosen to care about. But when coming into someone else's codebase, it's not helpful to say "this is low quality." That word is so vague that it loses all meaning. The code has a certain set of properties, like testability or complexity, and when talking about improving it we need to be precise in our language or we're just saying "this is bad, you're bad, I know better than you."