I like your response. I will question parts of it to make it even better
Good code does what it's supposed to.
But how to know what it suppose to do? We can write specification, but typical software specifications are partials, they are not formal specifications. Not a lot of people write models and check it with TLA+, right?
It can be quite expensive to write the specification. And this is hard to write full specification if you don't know full requirements, if your business needs to response to market changes.
The second part it is quite hard to verify that software is working according to the specification, we can prove that some portion of software confirms to some portion of spec, but to prove it confirms 100% we need to use formal verification, which is hard and expensive.
Good code is easy to read and maintain
Readability. I agree. But this means we need to give definition for readability to accomplish definition of good/bad code.
Without context or a stated purpose, it's not fair to judge code in a vacuum.
💯this what frustrates me when people use this phrase in the context "bad code is bad". Bad for what? Maybe there were reasons for it?
Bad code can be replaced. If it can't be replaced, problem not in the code, but in communication - nobody took time to write down all requirements in any other form rather than code, and nobody can reverse engineer this code. This is not a bad code problem, this is organisational problem.
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 like your response. I will question parts of it to make it even better
But how to know what it suppose to do? We can write specification, but typical software specifications are partials, they are not formal specifications. Not a lot of people write models and check it with TLA+, right?
It can be quite expensive to write the specification. And this is hard to write full specification if you don't know full requirements, if your business needs to response to market changes.
The second part it is quite hard to verify that software is working according to the specification, we can prove that some portion of software confirms to some portion of spec, but to prove it confirms 100% we need to use formal verification, which is hard and expensive.
Readability. I agree. But this means we need to give definition for readability to accomplish definition of good/bad code.
💯this what frustrates me when people use this phrase in the context "bad code is bad". Bad for what? Maybe there were reasons for it?
Bad code can be replaced. If it can't be replaced, problem not in the code, but in communication - nobody took time to write down all requirements in any other form rather than code, and nobody can reverse engineer this code. This is not a bad code problem, this is organisational problem.