I'm not a real fan of assigning a context-independent global value label like "good" or "bad" to code. While there probably are examples of truly "bad in all r

I'm not a real fan of assigning a context-independent global value label like "good" or "bad" to code. While there probably are examples of truly "bad in all respects, in any context" code, the vast majority of code that I've seen tends to fit more into "<this attribute> of the code could/should probably be improved when using it in <this context>". I find that viewing (and discussing) code this way has a lot of benefits: * It is really hard for a single global negative value judgement made about code to not be taken personally by the person who wrote it (e.g., "your code sucks" == "you suck"). This is much easier to avoid when talking about attributes of a thing, since (a) it comes across as more objective than subjective, (b) gives plenty of opportunities for acknowledging aspects of the code that _don't_ suck, and (c) lends itself to much more of a "give and take" discussion. * It gives you the opportunity to talk about "figures of merit" and trade-offs that are the reality of engineering, but rarely taught in schools (e.g., readability/development cost/flexibility vs. performance, etc.) * It gives you a framework for explaining why things like idiomatic style, "principle of least astonishment", and general elegance actually contribute to code quality (and aren't just excuses for subjective attacks).