与其让他们写代码，不如让他们维护代码。

除非他们不得不维护他们那堆冒着热气的意大利面，否则他们永远不会明白自己在编码方面有多糟糕。

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

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

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

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

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

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

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

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.

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

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

在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评，而不是对他们自己的批评。

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

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

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

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

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