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

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

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

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

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

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

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

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

我穿上长袍，打开一罐苏格拉底方法。

苏格拉底方法以古希腊哲学家苏格拉底的名字命名，是一种哲学探究的形式，提问者探究他人立场的含义，以激发理性思考和阐明思想。这种辩证方法经常涉及到一种对立的讨论，在这种讨论中，一种观点的辩护与另一种观点相对抗;一个参与者可能会导致另一个人在某种程度上自相矛盾，加强询问者自己的观点。

人们编写糟糕的代码只是无知的一种症状(这与愚蠢不同)。这里有一些对付这种人的技巧。

Peoples own experience leaves a stronger impression than something you will say. Some people are not passionate about the code they produce and will not listen to anything you say Paired Programming can help share ideas but switch who's driving or they'll just be checking email on their phone Don't drown them with too much, I've found even Continuous Integration needed to be explained a few times to some older devs Get them excited again and they will want to learn. It could be something as simple as programming robots for a day TRUST YOUR TEAM, coding standards and tools that check them at build time are often never read or annoying. Remove Code Ownership, on some projects you will see code silos or ant hills where people say thats my code and you can't change it, this is very bad and you can use paired programming to remove this.

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