Privately inquire about some of the "bad" code segments with an eye toward the possibility that it is actually reasonable code, (no matter how predisposed you may be), or that there are perhaps extenuating circumstances. If you are still convinced that the code is just plain bad -- and that the source actually is this person -- just go away. One of several things may happen: 1) the person notices and takes some corrective action, 2) the person does nothing (is oblivious, or doesn't care as much as you do).

如果#2发生了，或者从你的角度来看，#1并没有带来足够的改进，并且它正在损害项目，并且/或对你造成了足够的影响，那么可能是时候在团队中开始建立/执行标准了。这需要管理层的支持，但只有从基层做起才最有效。

祝你好运。我能感受到你的痛苦，兄弟。

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

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

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

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).

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

祝你好运。

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

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.

坦白地说，我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时，他的代码就会更好。

也就是说，我认为不可能告诉某人他/她的代码不好，而不先让他/她解释它是做什么的，或者任何人应该如何增强它(比如，创建新功能或调试它)。

只有到那时，他们的大脑才会崩溃，任何人都能看到:

全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)

也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的，但它们离真正定义什么是好代码还很远。

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

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

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

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

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