Well, there's that, and there's also "bad code" as in "bad engineering", in the real-world sense of engineering. If someone build a bridge quick and dirty and it works for the task at hand, which is crossing some ravine/river, we could all just say "well, it got the job done, so it was good." But when it collapsing due to entirely foreseeable circumstances, and not necessarily because a lot more resources needed to be spent, but possibly just because someone
didn't know or didn't care to take the time to figure out the common failure cases, then that's bad engineering.
That happens in code all the time. People do things in ways that are prone to problems because either they don't have the experience to know better, or they didn't take the time to think about the domain. I would call that "bad code", no matter how pretty it looks or understandable it is.
Part of the problem is that "good" and "bad" are far too vague, so everyone will bring their own meaning. You might see people using "bad" to mean unclear, but I would count that as a sign of progress. A imagine a "bad" mechanical in this day and age engineer is someone that does stuff that costs more money, either now or later when it breaks early, but still produces mostly safe constructs because that portion of the job is highly constrained, and when they fail there, they often aren't just "bad", but may be criminally negligent if they failed to adhere to both the law and industry best practices.
If were getting to the stage that "bad" programmers are just ones that write unclear code, that's a huge step up. Unfortunately, I don't think we are there.
