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

进行代码审查，并从审查你的代码开始。

这将使人们在整个代码评审过程中感到轻松，因为您是通过评审自己的代码而不是他们的代码来开始这个过程的。从你的代码开始也会给他们提供如何做事的好例子。

使用一些wiki软件在你的网络上创建一个wiki。

在你的网站上开始一个叫做“最佳实践”或“编码标准”的类别。

把每个人都指向它。允许反馈。

当您发布软件时，让负责将代码放入构建中的人员向开发人员推送，让他们指向上面的Wiki页面。

我曾在我的组织中这样做过，人们花了几个月的时间才真正熟悉使用Wiki，但现在它是一个不可或缺的资源。

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

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

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

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

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

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

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

这完全取决于你写作的文化。在一个自由软件项目中，你告诉他们他们写的代码不好，并给出积极的建议、改进方法和反馈。你也可以给他们的代码发送一个补丁。

一封友好的电子邮件也不会有什么坏处。