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

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

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

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

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

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

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

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

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

如果你有一个松散的编码标准，能够指出这一点，或者表明你不能遵循代码，因为它不是正确的格式可能是值得的。

如果您没有编码格式，现在将是一个好时机。类似于这个问题的答案可能会有帮助:https://stackoverflow.com/questions/4121/team-coding-styles

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

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

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

在他面前重构他的代码，并显示两个版本之间的差异。他肯定会喜欢的。