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

首先，我会注意不要太快下结论。有些代码很容易被认为是坏的，尽管可能有很好的理由(例如:使用带有奇怪约定的遗留代码)。但让我们暂时假设他们真的很糟糕。

你可以建议建立一个基于团队输入的编码标准。但是你真的需要考虑他们的意见，而不仅仅是强加你对好的代码应该是什么样子的看法。

另一种选择是把技术书籍带进办公室(《代码完成》、《有效的c++》、《实用的程序员》……)，并主动把它借给别人(“嘿，我用完了，有人想借吗?”)

并不是说我真的要在这个问题上增加那么多，但我必须同意，在处理这个问题时，最重要的两件事是解释你的推理，以及允许有问题的编码器解释他们的推理。坏代码不是凭空而来的(是的，“坏代码”当然是一个值得讨论的术语——我在某种程度上假设在这种情况下，您可以定义什么是好代码和坏代码)。

我发现提问式、教育性的方法对我的团队很有效。我从来不会在没有任何讨论或解释的情况下说“这样做”。

虽然你应该对这个问题有点敏感，但你不能粉饰这个问题。理想的情况是，您的团队正在考虑他们正在编写的代码，而不只是考虑代码在做什么，而是考虑它是如何编写的。

最后，我想补充一点，关于这个主题有很多值得探索的书籍——目前我最喜欢的是微软。net BCL团队的Brad Abrams和Krystof Kwalina(等人)所著的《框架设计指南》。它在讨论和解释所做的决定方面做得很出色，并展示了内部没有遵循指导方针的地方以及由此产生的后果。

耐心再怎么强调都不为过。我见过这种完全事与愿违的事情，主要是因为有人希望现在就发生变化。相当多的环境需要进化的好处，而不是革命。今天强行改变，可能会给所有人带来一个非常不愉快的环境。

接受是关键。你的方法需要考虑到你所处的环境。

听起来你所处的环境有很多“个性”。所以…我不建议使用一套编码标准。你会发现你想把这个“有趣”的项目变成一个高度结构化的工作项目(哦，太好了，接下来是什么……功能文件?)相反，正如其他人所说，你必须在一定程度上处理它。

Stay patient and work toward educating others in your direction. Start with the edges (points where your code interacts with others) and when interacting with their code try to take it as an opportunity to discuss the interface they've created and ask them if it would be okay with them if it was changed (by you or them). And fully explain why you want the change ("it will help deal with changing subsystem attributes better" or whatever). Don't nit-pick and try to change everything you see as being wrong. Once you interact with others on the edge, they should start to see how it would benefit them at the core of their code (and if you get enough momentum, go deeper and truly start to discuss modern techniques and the benefits of coding standards). If they still don't see it... maybe you'll need to deal with that within yourself (especially on a "fun" project).

耐心。进化，而不是革命。

祝你好运。

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

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

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