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.
In my example, two codebases (or toasters, I guess) are outwardly identical. They all pass the same tests, or meet the same acceptance criteria so the end user sees them as equivalent, but one has something that makes people complain about its "quality".
Let's say it's that the author has used funky variable names like x, k and thingy. If the code is never updated in the future, that's fine, I guess, but the implication is that the developer will do that on their next project where it'll suddenly be important.
You're hoping that nobody else will ever have to maintain it, and saying that's not part of the requirements isn't good enough to give it a free pass, to my mind.
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.
I disagree.
In my example, two codebases (or toasters, I guess) are outwardly identical. They all pass the same tests, or meet the same acceptance criteria so the end user sees them as equivalent, but one has something that makes people complain about its "quality".
Let's say it's that the author has used funky variable names like
x,kandthingy. If the code is never updated in the future, that's fine, I guess, but the implication is that the developer will do that on their next project where it'll suddenly be important.You're hoping that nobody else will ever have to maintain it, and saying that's not part of the requirements isn't good enough to give it a free pass, to my mind.
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."