没有人喜欢听别人说他们的工作很糟糕，但任何理智的人都会欢迎指导和避免不必要工作的方法。

有一种教学流派甚至说，你不应该指出错误，而应该专注于做对的事情。例如，与其指出难以理解的代码不好，不如指出他们的代码特别容易阅读的地方。在第一种情况下，你会引导其他人像蹩脚程序员一样思考和行动。在后一种情况下，你会像一个熟练的专业人士一样思考。

我真的很喜欢EnderMB的回答，但我想补充一点:

培养一种鼓励讨论代码质量的环境，而不是将其视为敏感或禁忌。例如，我曾在一个开源项目(一个Python库)中工作，团队经常讨论新代码和错误修复。不仅可以说“嘿，我认为这样做更好”，而且这实际上是被鼓励的，也是我们用于维护高质量代码的过程的一部分。

我知道不是每个环境都有利于这种过程，但它确实对我们很有效。每一次代码提交并不一定是一次委员会会议，但它应该是完全可以接受的，您可以讨论有问题的或非最优的代码并寻求改进。毕竟，更好的代码对团队中的每个人都有好处，团队合作的一个主要概念是一起工作，而不是松散的个人团体。

可能在效果后有点晚了，但这就是一致认可的编码标准是件好事的地方。

并不是说我真的要在这个问题上增加那么多，但我必须同意，在处理这个问题时，最重要的两件事是解释你的推理，以及允许有问题的编码器解释他们的推理。坏代码不是凭空而来的(是的，“坏代码”当然是一个值得讨论的术语——我在某种程度上假设在这种情况下，您可以定义什么是好代码和坏代码)。

我发现提问式、教育性的方法对我的团队很有效。我从来不会在没有任何讨论或解释的情况下说“这样做”。

虽然你应该对这个问题有点敏感，但你不能粉饰这个问题。理想的情况是，您的团队正在考虑他们正在编写的代码，而不只是考虑代码在做什么，而是考虑它是如何编写的。

最后，我想补充一点，关于这个主题有很多值得探索的书籍——目前我最喜欢的是微软。net BCL团队的Brad Abrams和Krystof Kwalina(等人)所著的《框架设计指南》。它在讨论和解释所做的决定方面做得很出色，并展示了内部没有遵循指导方针的地方以及由此产生的后果。

如果可能的话，确保他们明白你是在批评他们的代码，而不是针对他们个人。

重要的是激励和指导人们，即使有人明显犯了错误，也要表现出尊重。但是，不仅要有指导的方法，而且要有说明错误就是错误的方法。糟糕的代码应该做得更好。这不是可选的。从主管的角度来看，员工应该知道哪些代码是可以的，哪些是不可以的。它仍然应该以尊重和激励那些负责任的人来改善。