First of all, I don't think that having bad code is a bad thing. It's called technical debt and is totally acceptable. Bad code can become good code and vice versa.
As for the definition of bad code, at the end of the day, a piece of software tries to solve a problem. As long as that problem is being solved, we are talking about good code. When it fails to solve this problem or possible new problems that will arrive as time passes, then we start talking about bad code and the question becomes: What level of bad is this code at?
Then there is only one parameter to consider. How easy it is to extend/maintain/change it. That of course, is a whole chapter by it-self:
is it really reflective of the actual real-world problem that it tries to solve?
are there good tests that you can rely on?
is it readable in a way that you can understand what you need to do?
is there documentation that you can refer to when something doesn't really make sense?
First of all, I don't think that having bad code is a bad thing. It's called technical debt and is totally acceptable. Bad code can become good code and vice versa.
👍
As for the definition of bad code, at the end of the day, a piece of software tries to solve a problem. As long as that problem is being solved, we are talking about good code.
I'm not sure if everybody would agree to call it good code, but I feel wrong calling it bad. I feel that this dichotomy of good/bad is wrong by itself. Good/bad is broad category, with ambiguous definition. For example, it is fair to say this code is hard to read or this code hard to modify or this code is undocumented etc. but if it works and helps people I wouldn't call it bad...
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.
Short answer: i2.wp.com/commadot.com/wp-content/...
First of all, I don't think that having bad code is a bad thing. It's called technical debt and is totally acceptable. Bad code can become good code and vice versa.
As for the definition of bad code, at the end of the day, a piece of software tries to solve a problem. As long as that problem is being solved, we are talking about good code. When it fails to solve this problem or possible new problems that will arrive as time passes, then we start talking about bad code and the question becomes: What level of bad is this code at?
Then there is only one parameter to consider. How easy it is to extend/maintain/change it. That of course, is a whole chapter by it-self:
What do you think?
👍
I'm not sure if everybody would agree to call it good code, but I feel wrong calling it bad. I feel that this dichotomy of good/bad is wrong by itself. Good/bad is broad category, with ambiguous definition. For example, it is fair to say this code is hard to read or this code hard to modify or this code is undocumented etc. but if it works and helps people I wouldn't call it bad...