你如何告诉别人他们在写错误的代码？
我一直在和一小群人一起进行编码项目，以获得乐趣。 这是一个有组织，相当有凝聚力的小组。 与我共事的人都有各种与编程相关的技能，但其中一些人使用的是较老的或完全错误的方法，比如全局variables过大，命名惯例不佳等等。 虽然事情有效，但执行情况很差。 有礼貌地询问或介绍他们使用更好的方法学，而不是以质疑（或侮辱）他们的经验和/或教育？
介绍一些问题，使他们认识到他们所做的是错误的。 例如，问这些问题：
你为什么决定把这个全球variables？
你为什么给它这个名字？
那很有意思。 我通常这样做，因为[插入原因为什么你更好]
这样工作吗？ 我通常[插入你如何使他们看起来愚蠢]
我认为这样做的理想方式是巧妙地问他们为什么他们编码一定的方式。 你可能会发现他们认为其他方法有好处。 除非我知道他们编码风格的原因是由于错误的信息，否则我绝不会在没有理由的情况下判断我的方式。 最好的办法就是问问他们为什么select这种方式。 一定要对他们的推理感兴趣，因为那是你需要攻击的，而不是他们的能力。
编码标准肯定会有所帮助，但如果是每个软件项目的答案，那么我们都会在天堂的私人岛屿上啜饮鸡尾酒。 实际上，我们都很容易出现问题，软件项目的成功率还是很低的。 我认为这个问题大部分来自个人的能力，而不是习惯的问题，这就是为什么当问题出现丑陋的时候，我build议把问题作为一个整体来解决。
最重要的是， 不要立即假定你的方式更好 。 事实上，这可能是，但我们正在处理另一个人的意见，对他们来说，只有一个解决办法。 永远不要说你的方式是更好的方法，除非你想让他们看到你是一个自负的失败者。
开始做代码评论或结对编程。
如果团队不会去那些，请尝试每周的devise评论。 每个星期，会议一个小时，谈论一个代码。 如果人们看起来很防守，那么至less在开始的时候，select一个没有任何人情感的旧代码。
至于@JesperE：说，重点是代码，而不是编码器。
当你看到你认为应该不同的东西时，但是其他人不会以同样的方式看待它，那么首先要提出导致缺陷的问题，而不是指出问题。 例如：
全局 ：你认为我们会想要多于一个吗？ 你认为我们会想要控制访问这个？
可变状态 ：你认为我们会想从另一个线程操纵这个吗？
我还发现把注意力集中在我可以帮助人们放松的限制上是有帮助的。 例如：
长时间的function ：我的大脑不够大，无法一次完成所有这一切。 我们如何制作可以处理的小片？
不好的名字 ：读清晰的代码时，我会感到困惑; 当名字有误导性时，我就没有希望了。
最终，你的目标不是要教你的团队如何编写更好的代码。 这是在你的团队中build立一种学习的文化。 每个人都希望别人帮助成为更好的程序员。
介绍一个代码标准的概念。 关于代码标准最重要的是它提出了代码库中一致性的想法（ 理想情况下 ，所有的代码应该看起来像它是一个人一次写的），这将导致更易于理解和维护的代码。
你必须解释为什么你的方式更好 。
解释为什么一个function比剪切和粘贴更好。
解释为什么一个数组比$ foo1，$ foo2，$ foo3好。
解释为什么全局variables是危险的，局部variables将使生活更轻松。
简单地去掉一个编码标准，说“做这个”是毫无价值的，因为它没有向程序员解释为什么这是一件好事。
首先，我小心不要太快判断。 当一些代码很糟糕的时候很容易被忽略，当时可能有很好的理由（例如：用古怪的代码来处理旧代码）。 但是现在假设他们真的很糟糕。
你可以build议根据团队的意见build立一个编码标准。 但是，你真的需要考虑他们的意见，而不是强加你的代码应该是什么好的愿景。
另一个select是将技术书籍带到办公室（Code Complete，Effective C ++，Pragmatic Programmer …），并提供给其他人（“嘿，我完成了这个，任何人都想借用它？ ）
如果可能的话，确保他们明白你是批评他们的代码 ，而不是他们个人。
build议一个更好的select，以非对抗的方式。
“嘿，我想这样也会起作用，你们觉得呢？ [屏幕上明显更好的代码的手势]
有代码审查，并开始审查您的代码。
这将使整个代码审查过程中的人们放心，因为您正在开始审查自己的代码而不是他们自己的代码。 从你的代码开始，也将给他们如何做事的好例子。
他们可能会认为你的风格也太臭了。 让团队一起讨论一组一致的编码风格指南。 同意某事。 是否适合你的风格是不是问题，只要一致就是解决问题的关键。
举例来说。 给他们正确的方法。
慢慢来。 不要为了每一个小小的错误而鞭打他们，只要从真正重要的事情开始。
代码标准的想法是一个很好的。
但是不要说任何话，特别是因为它是为了好玩，大概是你和朋友在一起的人。 这只是代码…
格里·温伯格（Gerry Weinberg）的“计算机编程心理学”一书中有一些很好的build议 – 他的“自我编程”的整个概念都是关于如何帮助人们接受批评自己的代码，而不是批评自己。
不好的命名实践：总是不可原谅的。
是的，不要总是认为你的方式更好…这可能是困难的，但必须保持客观性。
我有一个编码器的经验，有这样可怕的function命名，代码比不可读的更糟糕。 这些函数说谎，代码是荒谬的。 而且他们保护/抵制别人改变他们的代码。 当他们非常有礼貌地对待他们时，他们承认这个名字不好，但是想保留他们对代码的所有权，并且会在“以后的日子”回去修复。 这是过去的事情，但是，如何处理错误已被确认，但受到保护的情况呢？ 这持续了很长时间，我不知道如何突破这个障碍。
全局variables：我自己并不喜欢全局variables，但我知道有一些优秀的程序员喜欢他们很多。 这样我就可以相信在许多情况下它们并不是那么糟糕，因为它们使得debugging变得简单易行。 （请不要火焰/ downvote我:)）归结起来，我已经看到了很多非常好的，有效的，无错的代码，使用全局variables（不放在我的！）和大量的越野车，不可能读取/维护/修复精心使用适当模式的代码。 也许有一个地方（尽pipe可能缩小）的全球变数？ 我正在考虑根据证据重新思考我的立场。
使用一些wiki软件在您的networking上启动wiki。
在您的网站上开始一个名为“最佳实践”或“编码标准”的类别。
指向大家。 允许反馈。
当你发布软件的时候，让那些把代码放到构build中的人推回到开发者身上，把他们指向Wiki页面。
我已经在我的组织中完成了这个工作，人们花了好几个月的时间才真正进入了使用维基的行列，但现在却成了这个不可或缺的资源。
如果你甚至有一个松散的编码标准，能够指出，或者表示你不能跟随代码，因为它不是正确的格式可能是值得的。
如果你没有编码格式，现在是一个适当的时机。 像这个问题的答案可能会有所帮助： https : //stackoverflow.com/questions/4121/team-coding-styles
我总是用“这就是我要做的”的方式去做。 我不会试着去教他们，告诉他们他们的代码是垃圾的，但是只是给出一个替代的观点，希望能够给他们看一些显然是有点整洁的东西。
有问题的人员准备向小组的其他成员介绍他们编写的代表性模块的代码，然后让问答处理（相信我，会的，如果这是一个好的小组，它甚至不应该变丑）。
我爱编码，从来没有任何关于信息学的任何课程，我开始很糟糕，开始学习示例，但自从我读了“四人帮”书以来，我始终记住和记住的是：
“每个人都可以编写机器可以理解的代码，但是并不是所有的人都可以编写人类理解的代码”
考虑到这一点，代码中有很多工作要做;）
我没有一个toga，并打开一jarsocratic的方法。
以古典希腊哲学家苏格拉底命名的苏格拉底方法 ，是一种哲学探究的forms，提问者探究他人立场的含义，刺激理性思考，阐释思想。 这种辩证的方法经常涉及一种观点的辩护与另一种观点的对立讨论。 一位参与者可能会以某种方式引导另一位自相矛盾，加强询问者的自己的观点。
这里的很多答案都与代码格式有关，这些代码格式现在并不特别相关，因为大多数IDE会按照您select的样式重新格式化您的代码。 真正重要的是代码是如何工作的，海报是正确的，可以查看全局variables，复制和粘贴代码，以及我的宠物，命名约定。 有这样的代码错误的东西，它与格式很less。
好的一面是，大部分情况都是不好的，这些原因通常是可以量化和解释的。 所以，以非对抗的方式解释原因。 在很多情况下，你甚至可以给作家情景的问题变得明显。
我不是我的项目的主要开发人员，因此不能强加编码标准，但是我发现，不好的代码通常会导致问题的提前，而不是晚些时候，而当我遇到一个更清晰的想法或解决scheme。
通过在当时不插手，采取更自然的方式，我已经获得了更多的领导信任，他经常向我提出的想法，包括我的项目使用的build筑devise和部署策略。
编写不好的代码的人只是无知的performance（这与愚蠢不同）。 这里有一些与这些人打交道的提示。
- 人民自己的经历比你要说的东西留下更强烈的印象。
- 有些人对自己制作的代码不感兴趣，也不会听你说的话
- 配对编程可以帮助分享想法，但切换谁的驾驶，或他们将只是在他们的手机上检查电子邮件
- 不要把它们淹没太多，我甚至发现连续集成需要几次向一些老的开发者解释
- 让他们再次兴奋，他们会想学习。 这可能像一天编程机器人一样简单
- 相信你的团队，在编译时检查它们的编码标准和工具通常不会被读取或讨厌。
- 删除代码所有权，在一些项目中，你会看到代码筒仓或ant山，人们说，我的代码，你不能改变它，这是非常糟糕的，你可以使用配对编程来消除这一点。
不要让他们写代码，让他们维护他们的代码。
直到他们不得不保持他们热气腾腾的一堆意大利面，他们永远不会明白他们在编码上有多糟糕。
我无法强调足够的耐心。 我已经看到这种事情完全适得其反，主要是因为有人希望现在发生变化。 不less环境需要进化的好处，而不是革命。 而今天通过强迫变革，可以为所有人创造一个非常不愉快的环境。
买入是关键。 而你的方法需要考虑到你所处的环境。
这听起来像你在一个有很多“个性”的环境中。 所以…我不会提出一套编码标准。 它会碰到你想要把这个“有趣”的项目，并把它变成一个高度结构化的工作项目（哦，太棒了，下一步…function文件？）。 相反，正如别人所说，你必须在一定程度上处理它。
保持耐心，努力教育他人在你的方向。 从边缘开始（代码与其他人交互的地方），并与代码进行交互时，试着把它作为讨论他们创build的接口的一个机会，并询问他们是否可以改变它们（通过你或他们）。 并完全解释为什么你想要改变（“这将有助于更好地处理改变的子系统属性”或其他）。 不要挑剔，试图改变你认为是错误的一切。 一旦你与其他人进行了交stream，他们应该开始看到如何让他们在代码的核心中受益（如果你有足够的动力，更深入，真正开始讨论现代技术和编码标准的好处）。 如果他们仍然没有看到…也许你需要在自己内部处理（特别是在一个“有趣”的项目）。
忍耐。 进化，而不是革命。
祝你好运。
没有人喜欢听别人说他们的工作很糟糕，但任何理智的人都会欢迎指导和避免不必要的工作。
一所教学学校甚至说，你不应该指出错误，而是把重点放在正确的方面。 例如，你不应该把难以理解的代码指出来，而应该指出他们的代码特别容易阅读。 在第一种情况下，你正在启动其他人思考和行为像蹩脚的程序员。 在后面的例子中，你正在像一个熟练的专业人员那样思考。
我和我一起工作的人有一个类似的senario。他们没有像我这样做的代码暴露，但他们仍然在编码有用。
而不是让我做他们想做的事，然后回头编辑整个事情。 我通常只是坐下来向他们展示两种做事的方式。 我们的方式和方式，从这里我们讨论每种方法的正反两方面，从而更好地理解和更好的结束我们应该如何去编程。
这是真正的翻新部分。 有时他们会提出一些问题，即使我没有答案，经过研究，我们都会得到更好的方法论和结构的概念。
- 讨论。
- 告诉他们为什么
- 甚至不要以为你总是对的。有时他们甚至会教你新的东西。
那就是如果我是你，我会做什么：D
效果可能稍晚一点，但这是一个商定的编码标准是一件好事。
我坦率地认为，当更改，debugging，浏览，理解，configuration，testing和发布（更简单）更容易时，某人的代码更好。
这就是说，我认为不可能先告诉别人他/她的代码是不好的，而不必先解释他们做了什么，或者以后应该如何增强它（比如创build新的function或debugging它）。
只有这样，他们的思想才会出现，任何人都能看到：
- 全局variables值的变化几乎总是不可测的
- 巨大的function难以阅读和理解
- 模式使你的代码更容易提升（只要你遵守规则）
- （等…）
也许一对结对编程应该做的伎俩。 至于执行编码标准 – 它有帮助，但是他们距离真正定义好的代码太远了。
你可能想把重点放在不好的代码的影响上，而不是把你的主观看法看作是好还是坏的风格。
私下询问一些“不好”的代码段，并着眼于它实际上是合理的代码的可能性（不pipe你可能有多么倾向于），或者可能是情有可原的情况。 如果你仍然相信代码是非常糟糕的，并且源代码实际上就是这个人，那么就离开吧。 可能会发生以下几种情况之一：1）该人注意并采取一些纠正措施; 2）该人不做任何事情（无视或不关心）。
如果＃2发生了，或者＃1没有从你的观点来看有足够的改善，并且对项目造成了伤害，并且/或者对你有足够的冲击，那么可能是时候开始一个运动来build立/执行标准团队。 这需要pipe理层的支持，但在基层煽动下最为有效。
祝你好运。 我感觉到你的痛苦哥哥。
