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

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

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

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

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

祝你好运。

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

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

你必须解释为什么你的方法更好。

解释为什么函数比剪切和粘贴更好。

解释为什么数组比$foo1， $foo2， $foo3更好。

解释为什么全局变量是危险的，而局部变量会让事情变得更容易。

简单地提出一个编码标准，然后说“这样做”是没有价值的，因为它没有向程序员解释为什么这是一件好事。

您可能想要关注坏代码的影响，而不是您对它的风格是好是坏的主观看法。

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

这完全取决于你写作的文化。在一个自由软件项目中，你告诉他们他们写的代码不好，并给出积极的建议、改进方法和反馈。你也可以给他们的代码发送一个补丁。

一封友好的电子邮件也不会有什么坏处。