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

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

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

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

如果你有一个松散的编码标准，能够指出这一点，或者表明你不能遵循代码，因为它不是正确的格式可能是值得的。

如果您没有编码格式，现在将是一个好时机。类似于这个问题的答案可能会有帮助:https://stackoverflow.com/questions/4121/team-coding-styles

提出问题，让他们意识到他们所做的是错误的。例如，问这样的问题:

你为什么决定让它成为一个全局变量? 你为什么给它起这个名字? 这很有趣。我通常这样做，因为[插入你更好的原因] 这样行吗?我通常[插入你会如何让他们看起来很傻]

我认为最理想的方法是巧妙地问他们为什么要这样编码。你可能会发现他们相信其他方法也有好处。除非我知道他们的编码风格是由于错误信息，否则我永远不会在没有充分理由的情况下判断我的方法更好。最好的办法就是问他们为什么选择那样做;一定要让自己听起来对他们的推理感兴趣，因为这才是你需要攻击的，而不是他们的能力。

编码标准肯定会有所帮助，但如果它是每个软件项目的答案，那么我们都只能在天堂的私人岛屿上啜饮鸡尾酒了。在现实中，我们都容易遇到问题，软件项目的成功率仍然很低。我认为问题主要是源于个人能力，而不是传统的问题，这就是为什么当问题浮出水面时，我建议大家一起解决问题。

最重要的是，不要马上认为你的方法更好。在现实中，可能是这样，但我们在处理另一个人的意见，对他们来说只有一个解决方案。永远不要说你的方式是更好的方式，除非你想让他们认为你是一个自鸣得意的失败者。

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

你必须解释为什么你的方法更好。

解释为什么函数比剪切和粘贴更好。

解释为什么数组比$foo1， $foo2， $foo3更好。

解释为什么全局变量是危险的，而局部变量会让事情变得更容易。

简单地提出一个编码标准，然后说“这样做”是没有价值的，因为它没有向程序员解释为什么这是一件好事。