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

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

进行代码审查，并从审查你的代码开始。

这将使人们在整个代码评审过程中感到轻松，因为您是通过评审自己的代码而不是他们的代码来开始这个过程的。从你的代码开始也会给他们提供如何做事的好例子。

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

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

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

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

代码标准的想法是一个很好的想法。

但考虑一下不要说什么，尤其是因为这是为了好玩，而且大概是和你的朋友。这只是代码……

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