Any definition that a lot of developers can all agree with is going to be pretty general. I'd define bad code in light of what ideal good code is.
Good code does what it's supposed to. Bad code doesn't do what it's supposed to.
Good code is easy to read and maintain. Bad code is difficult for your successor (or yourself) to read and modify.
Reading good code can be surprising, whether it teaches you a new concept or has an elegant solution. Mostly it's obvious and straightforward to the point of being boring. Reading bad code can be surprising and holds your interest with pitfalls and unexpected behavior.
Good code uses the right tool for the job and makes it clear the developer is "thinking in" that language and its strengths. Bad code disregards the standards and solves problems with a club (e.g. loops and complicated flow control in your routine SQL queries is a bad sign).
Readability is a tricky one, because it depends so much on the context and the reader. A novice will have a hard time following very dense code written to solve a difficult problem, but that doesn't automatically mean it's bad code.
Maybe this question of definitions is missing a piece. The more complete question might ask "bad code for what?" Without context or a stated purpose, it's not fair to judge code in a vacuum.
There's a lot of code written for code golf. It's largely impenetrable and undocumented and probably doesn't even solve a real problem! Does that mean it's bad? Because I think it's beautiful and clever and perfectly suited to the situation.
And any written definition for judging good code from bad is going to be either so general or so contentious as to be useless without taking context into account.
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.
Oh man the point you made about good code being so elegant you learn from it. I started a new job as a software developer. The database was down for a week so I spent a week reading line by line the code. There are two parts to the code.
Complex models written by non programmers.
Refactored code for processing the models with multi-processing.
The refactored code was so easy to read and understand. I was able to learn from it.
Example using wrappers in Python to deserialize JSON files instead of manually decoding
I recently started debugging part of the models that haven't been refactored and it's so bad I don't think even the guy who wrote it knows what it is doing.
I recently started debugging part of the models that haven't been refactored and it's so bad I don't think even the guy who wrote it knows what it is doing.
But the question is your problem in the bad code itself or the fact that there is no other documentation of requirements rather than code itself? (Otherwise you can throw it away and rewrite from the scratch).
Do you know in which conditions this code was written?
Maybe it was first job of the person? Then poor quality is due to lack of mentorship and lack of code reviews (bad culture)
Maybe there was pressure from the management, which lead to the result (again bad culture)
The first person who programmed it has a PhD in statistics and has little to no background in programming. The "documentation" I have to compare it against is an Excel sheet with complex formulas. The logic in the Excel is completely different from the logic in the Python he wrote.
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.
Any definition that a lot of developers can all agree with is going to be pretty general. I'd define bad code in light of what ideal good code is.
Readability is a tricky one, because it depends so much on the context and the reader. A novice will have a hard time following very dense code written to solve a difficult problem, but that doesn't automatically mean it's bad code.
Maybe this question of definitions is missing a piece. The more complete question might ask "bad code for what?" Without context or a stated purpose, it's not fair to judge code in a vacuum.
There's a lot of code written for code golf. It's largely impenetrable and undocumented and probably doesn't even solve a real problem! Does that mean it's bad? Because I think it's beautiful and clever and perfectly suited to the situation.
And any written definition for judging good code from bad is going to be either so general or so contentious as to be useless without taking context into account.
So, my definition of bad code? It depends.
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.
Oh man the point you made about good code being so elegant you learn from it. I started a new job as a software developer. The database was down for a week so I spent a week reading line by line the code. There are two parts to the code.
The refactored code was so easy to read and understand. I was able to learn from it.
Example using wrappers in Python to deserialize JSON files instead of manually decoding
I recently started debugging part of the models that haven't been refactored and it's so bad I don't think even the guy who wrote it knows what it is doing.
But the question is your problem in the bad code itself or the fact that there is no other documentation of requirements rather than code itself? (Otherwise you can throw it away and rewrite from the scratch).
Do you know in which conditions this code was written?
The first person who programmed it has a PhD in statistics and has little to no background in programming. The "documentation" I have to compare it against is an Excel sheet with complex formulas. The logic in the Excel is completely different from the logic in the Python he wrote.