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

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

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

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

让有问题的人就他们编写的代表性模块的代码向小组的其他成员准备一份演示文稿，并让问答环节来处理(相信我，它会的，如果这是一个优秀的小组，它甚至不应该变得丑陋)。

他们可能也认为你的风格很糟糕。让团队一起讨论一套一致的编码风格指南。同意某事。这是否适合你的风格并不是问题，选择任何风格只要它是一致的才是重要的。

我和和我一起工作的人有类似的情况。他们不像我那样接触编码，但他们在编码方面仍然很有用。

而不是我让他们做他们想做的然后回去编辑整篇文章。我通常只是让他们坐下来，告诉他们两种做事的方法。他们的方式和我的方式，从这里我们讨论了每种方法的优缺点，因此对我们应该如何进行编程有了更好的理解和更好的结论。

这是真正令人惊讶的部分。有时他们会提出一些连我都不知道答案的问题，经过研究，我们都对方法论和结构有了更好的概念。

讨论。 告诉他们为什么 甚至不要认为你总是对的。有时甚至他们也会教你一些新东西。

如果我是你，我也会这么做

我建议对这个问题采取积极的态度。与其指责你的同事使用糟糕的风格，不如就风格和评论准则提出一些建议，让你的整个团队都能遵循。

例如，如果你主要是一个。net商店，建议坚持微软的c#风格和注释指南，因为这将使你更符合社区的标准实践。

您还可以指出一些遵循统一代码风格的例子——例如，如果不熟悉代码库的人查看了它，他们就不必破译多种风格。可以这样想:如果你正在读一本书，很容易看出每一章都是由不同的人写的，你会在读了几章后感到困惑吗?

我认为重要的是不要用消极的方式批评你的同事。最好是向人们推销改变的好处，这比说服他们写的是糟糕的代码要容易得多。

在他面前重构他的代码，并显示两个版本之间的差异。他肯定会喜欢的。