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

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

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

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

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

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

重要的是激励和指导人们，即使有人明显犯了错误，也要表现出尊重。但是，不仅要有指导的方法，而且要有说明错误就是错误的方法。糟糕的代码应该做得更好。这不是可选的。从主管的角度来看，员工应该知道哪些代码是可以的，哪些是不可以的。它仍然应该以尊重和激励那些负责任的人来改善。

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

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

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

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

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