我很喜欢代码，在我的生活中从来没有上过任何与信息学相关的课程，我一开始很糟糕，开始从例子中学习，但自从我读了“四人帮”这本书以来，我一直记得并一直在我的脑海中:

“每个人都能写出机器能理解的代码，但不是所有人都能写出人类能理解的代码。”

考虑到这一点，在代码中有很多事情要做;)

这取决于程序员。有些人实际上喜欢听到“这太糟糕了”，因为他们知道代码很臭，但不知道为什么。

其他程序员需要更多的照顾。我发现告诉他们坏事是好的;“这不是写代码的好方法”，然后是一些指导“这里，看看我们是否这样做，它更可读/更少警告/诸如此类”。建设性的批评是有帮助的;如果你不能说到做到，最好不要评论，即使你知道这是不好的。

唯一一个两种方法都失败的人是一个固执的行政助理，他用VBscript写了大量的宏，一切都是逆向的。她竟然厚颜无耻地告诉我，我对计算机编程一窍不通，我可以向她学习。

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

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

以一种非对抗性的方式提出一个更好的选择。

“嘿，我觉得这个方法也可以。你们怎么看?”[用手势表示屏幕上的代码明显更好]

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并没有带来足够的改进，并且它正在损害项目，并且/或对你造成了足够的影响，那么可能是时候在团队中开始建立/执行标准了。这需要管理层的支持，但只有从基层做起才最有效。

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

介绍代码标准的思想。关于代码标准最重要的事情是它提出了代码库的一致性(理想情况下，所有的代码都应该看起来像由一个人一次编写的)，这将导致更容易理解和可维护的代码。