可能在效果后有点晚了，但这就是一致认可的编码标准是件好事的地方。

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

这里的许多答案都与代码格式有关，但现在并不是特别相关，因为大多数ide将按照您选择的样式重新格式化代码。真正重要的是代码是如何工作的，海报是正确的查看全局变量，复制和粘贴代码，以及我的烦恼，命名约定。糟糕的代码是存在的，这与格式没有多大关系。

好的方面是，大多数情况下都有很好的原因，这些原因通常是可量化和可解释的。所以，用一种非对抗性的方式解释原因。在许多情况下，您甚至可以为作者提供问题变得明显的场景。

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

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

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

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

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

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

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

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

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

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

祝你好运。

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

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

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