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

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

这里的许多答案都与代码格式有关，但现在并不是特别相关，因为大多数ide将按照您选择的样式重新格式化代码。真正重要的是代码是如何工作的，海报是正确的查看全局变量，复制和粘贴代码，以及我的烦恼，命名约定。糟糕的代码是存在的，这与格式没有多大关系。

好的方面是，大多数情况下都有很好的原因，这些原因通常是可量化和可解释的。所以，用一种非对抗性的方式解释原因。在许多情况下，您甚至可以为作者提供问题变得明显的场景。

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

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

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

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

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

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

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

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

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

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

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

Privately inquire about some of the "bad" code segments with an eye toward the possibility that it is actually reasonable code, (no matter how predisposed you may be), or that there are perhaps extenuating circumstances. If you are still convinced that the code is just plain bad -- and that the source actually is this person -- just go away. One of several things may happen: 1) the person notices and takes some corrective action, 2) the person does nothing (is oblivious, or doesn't care as much as you do).

如果#2发生了，或者从你的角度来看，#1并没有带来足够的改进，并且它正在损害项目，并且/或对你造成了足够的影响，那么可能是时候在团队中开始建立/执行标准了。这需要管理层的支持，但只有从基层做起才最有效。

祝你好运。我能感受到你的痛苦，兄弟。

坦白地说，我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时，他的代码就会更好。

也就是说，我认为不可能告诉某人他/她的代码不好，而不先让他/她解释它是做什么的，或者任何人应该如何增强它(比如，创建新功能或调试它)。

只有到那时，他们的大脑才会崩溃，任何人都能看到:

全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)

也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的，但它们离真正定义什么是好代码还很远。