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

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

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.

根据我的经验，曾经有一段时间，我们想要将一个windows应用程序更改为一个web应用程序并进行优化，因为它更容易更新和维护。但由于我的朋友是windows应用程序的主要贡献者，他不允许更改，然后剩下的就是历史了。

寓意:为了代码优化和更好的维护，在任何编程环境中，重视组织的目标都比重视个人的目标更重要。

让有问题的人就他们编写的代表性模块的代码向小组的其他成员准备一份演示文稿，并让问答环节来处理(相信我，它会的，如果这是一个优秀的小组，它甚至不应该变得丑陋)。

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

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

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

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

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

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

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

您可能想要关注坏代码的影响，而不是您对它的风格是好是坏的主观看法。