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

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

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

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

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

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

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

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

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

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

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

没有人喜欢听别人说他们的工作很糟糕，但任何理智的人都会欢迎指导和避免不必要工作的方法。

有一种教学流派甚至说，你不应该指出错误，而应该专注于做对的事情。例如，与其指出难以理解的代码不好，不如指出他们的代码特别容易阅读的地方。在第一种情况下，你会引导其他人像蹩脚程序员一样思考和行动。在后一种情况下，你会像一个熟练的专业人士一样思考。

糟糕的命名习惯:总是不可原谅的。

是的，不要总是认为你的方式更好……这可能很困难，但必须保持客观性。

I've had an experience with a coder that had such horrible naming of functions, the code was worse than unreadable. The functions lied about what they did, the code was nonsensical. And they were protective/resistant to having someone else change their code. when confronted very politely, they admitted it was poorly named, but wanted to retain their ownership of the code and would go back and fix it up "at a later date." This is in the past now, but how do you deal with a situation where they error is ACKNOWLEDGED, but then protected? This went on for a long time and I had no idea how to break through that barrier.

Global variables: I myself am not THAT fond of global variables, but I know a few otherwise excellent programmers that like them A LOT. So much so that I've come to believe they are not actually all that bad in many situations, as they allow for clarity, ease of debugging. (please don't flame/downvote me :) ) It comes down to, I've seen a lot of very good, effective, bug free code that used global variables (not put in by me!) and great deal of buggy, impossible to read/maintain/fix code that meticulously used proper patterns. Maybe there IS a place (though shrinking perhaps) for global variables? I'm considering rethinking my position based on evidence.