我总是说‘这就是我要做的’。我不会试图教训他们，告诉他们他们的代码是垃圾，而只是给他们一个不同的观点，希望能向他们展示一些明显更整洁的东西。

以一种非对抗性的方式提出一个更好的选择。

“嘿，我觉得这个方法也可以。你们怎么看?”[用手势表示屏幕上的代码明显更好]

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

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

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

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

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

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

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

开始进行代码评审或结对编程。

如果团队不愿意这么做，那就尝试每周设计回顾。每周开一个小时的会，讨论一段代码。如果人们看起来很有戒心，那就选择那些没有人在情感上依恋的旧代码，至少在一开始是这样。

正如@ jesere所说，关注代码，而不是编码员。

当你看到一些你认为应该不同的东西，但别人不这么看的时候，那就开始问一些导致缺陷的问题，而不是指出它们。例如:

Globals:你认为我们还会想要更多这样的东西吗?你认为我们会想要控制它的使用权吗?

可变状态:你认为我们想要从另一个线程操纵它吗?

我还发现关注自己的局限性很有帮助，这可以帮助人们放松。例如:

长功能:我的大脑不够大，不能一次容纳所有这些。我们怎样才能做出更小的我能处理的东西呢?

坏名声:在阅读清晰的代码时，我很容易感到困惑;当名字被误导时，我就没有希望了。

最终，你的目标不是教会你的团队如何更好地编码。而是在你的团队中建立一种学习的文化。每个人都向他人寻求帮助，成为更好的程序员。

您可能想要关注坏代码的影响，而不是您对它的风格是好是坏的主观看法。