通过例子。告诉他们正确的道路。

慢慢来。不要因为他们的每一个小错误就立刻痛斥他们，要从真正重要的事情开始。

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

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

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

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

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

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

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

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

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

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

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

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

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

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