如何让开发人员遵循编码标准？

Question

如何让开发人员遵循编码标准？

在我们公司：

1. 我已经提供了文件，他们没有耐心阅读并遵循它。
2. 我曾经一次又一次地告诉他们“请这样做”他们点头表示，但仍然做错了方式
3. 我们第三次做了一个项目，但他们似乎还没有正确地遵循它。

我现在已经厌倦了这一点。设置编码标准并确保遵循编码标准的最佳方法是什么？

编辑：

我的团队中只有大约10名开发人员。由于从我们的管理层完成产品​​的压力越来越大，他们的压力越来越大，不会花时间发表评论并整理好代码。对此有什么解决方法？

Answer 1

自动化。

您可以将 StyleCop 和 FxCop （VS2008中的代码分析）集成到您的构建过程中。

因此，当某人检查违反规则的内容时，构建将会中断，他们将不得不修复它。如果您没有支持此功能的自动构建过程，则可以在代码审查等之前手动运行这些工具。

您可能无法找到符合您编码标准的完美匹配，但您应该能够获得非常接近的东西。

了StyleCop

http://code.msdn.microsoft.com/sourceanalysis

FxCop：

http://blogs.msdn.com/fxcop/

Answer 2

开发人员在编写标准时是否咨询过？我讨厌必须遵循有人提出的指导方针，并没有咨询一些开发人员。它一直在发生。

另一件让我感到困惑的事情就是有人给我指导线，但实际上并不适用于生产代码。理论上正确的做事方式和做事的正确方法有很大的不同。

Answer 3

去获得更多听话的开发者。

严肃地说：我可以为自己说，我倾向于忽视（或不愿意遵循）我认为完全不合理，过于专制或简单愚蠢的做法。试着和你的家伙说话，问他们对医生不喜欢什么。

Answer 4

你有标准。你有一个流程供他们遵循。如果他们不遵守，请终止他们并找到符合标准的合格人员。

更具体地说，

1. 在项目开始时，与团队一起审查标准。沟通他们必须遵守。
2. 在项目结束时，进行审核以确保他们得到遵守。如果不是，请与负责不跟踪的人员合作。询问有关原因的问题等。
3. 给他/她第二次机会。
4. 如果重复，请终止个人。

Answer 5

他们是无能，懒惰还是无知？

我对这种事情的体验是，它始于领导力和优先权。优先级，意味着人们弄清楚线条的绘制位置，并且它们就在那里。我能想到的一个例子是一位新的程序员正在接受一份由同一个人填补了12年的工作。他必须维护的代码是一个草率的混乱。所以他知道他可以逃脱谋杀......因为最后一个人自己离开了，在经历了12年的无能为力之后再也没有被解雇。

如果你已经把这条线拉得太远了，那么就把它控制好。明确地解雇其中一条，不遵守标准。

听起来你已经试图治愈愚昧人，只留下懒惰和无能......这两者都不值得治愈。如果我是你，我会宰杀牛群。如果这不起作用，请寻找管理层之外的工作。

编辑：为了应对您的“加压”，项目经理应尽力吸收尽可能多的压力。最好的经理知道他们团队的能力，并知道如何告诉管理层。你需要成为团队和管理层之间的联络人，如果管理层正在匆匆忙忙，你应该向他们表明质量会受到影响。如果有钱的人不像他们那样关心质量那么多......好吧，你不能对标准挑剔。如果他们想要质量，他们会倾听一位自信的经理，他告诉他们他的程序员无法在没有标准执行的情况下创建高质量，可维护的应用程序。

如果他们感到压力就是这样做的话，那么你需要努力吸收更多的压力，而不是让它变成你的团队。这是项目经理的重要组成部分。

Answer 6

听起来你不够受人尊重。

进行代码审查，并与团队讨论编码标准。也许他们不坚持，因为他们不同意。要灵活。

也许如果你第三次做一个项目，那就是你做错了。

Answer 7

你需要learn serenity！这是一种常见的情况。即使你变得更高级并且更能影响事物，你也无法做出完美的编码情况。尽量做到最好，尽可能做个好榜样。

知道所有超级巨星的同事也是永远不会消失的东西。 There are a few things you can do though

Answer 8

如果您有资历，那么请进行代码审查，并因未遵守编码标准而使其失败。如果它继续，你可以给他们一个正式的警告。如果它继续下去你可以解雇它们并让那些人在他们的生活中花费20分钟阅读编码标准文件。

我不知道您使用的是什么IDE，但Eclipse允许您设置可以在开发人员周围分发的代码格式化程序，因此这也可能是一个想法。

然而，可能存在潜在的问题 - 其他开发人员不喜欢您的编码标准。最好先找出是否属于这种情况。如果您的编码标准实际上不是您所用语言的通用标准，那么只要他们可以侥幸逃脱，他们就可能只是被动攻击。也许你应该让他们参与制定他们都满意的编码标准，主要是。

Answer 9

摆脱它们并找到新的。如果他们懒得做正确的事情，他们就不值得受雇。在这种经济形势下，早上你手上将有100份简历。

Answer 10

技术解决方案 如果您使用的是Team System，则可以使用checkin policies来强制执行。其他版本控制系统无疑支持类似的东西。你需要TFS Server Power tools。

<强>非技术 除了技术解决方案，您可能想要解释您需要这些编码标准（质量，法律等）的原因。他们可能会觉得政策过于严格，或者根本不了解必要性。 如果你能说服他们做这件事的必要，你就不再需要强迫他们了。

Answer 11

如果您的同事和管理层不关心代码质量，您不能强迫他们关心。如果你真的试图说服他们并且你被忽视了，那么你的角色就不是你的任务了。

  

我实在厌倦了自己重写那些糟糕的代码。

我认为是时候静静地开始寻找新工作了。同时，除了修复错误之外，还要抵制重写垃圾代码的诱惑。并试图让犯罪分子修复他们自己的错误。

话虽如此，团队领导有可能更关心这一点，而不是他正在放弃。他可能根本无法采取必要的行动来应对劣质文化。例如，如果项目落后，那么摆脱工作人员可能不是一种选择。或许他在人员配置问题上没有任何真正的影响力......而且罪犯也知道。

Answer 12

如果这真的很重要，那么你必须向他们证明他们为什么错了。

  

他们抓住并压制Throwable s

提出一些导致灾难的测试输入应该不是很难。

  

返回null s

这不像抑制Throwable那么严重，但仍然可能导致问题。显示他们的代码导致NullPointerException被抛出的位置。您还应该向他们展示要返回的内容而不是null（空数组，Null Object等）以及在调用代码中使用它的容易程度。

  

在大型循环中连接String

这并不是那么糟糕。如果是我，你必须告诉我，所讨论的循环是系统中的瓶颈，并且连接正在显着减慢速度。对应用程序进行基准测试并找出答案。

对于您认为存在问题的任何练习，您需要能够演示两件事：

1. 为什么这是错的。
2. 正确的方法。

如果你不能同时做到这两点，那么你就没有足够的理由改变他们的习惯。

Answer 13

我同意安东。你需要他们的支持，否则编码标准只是随意的规则，旨在给他们带来不便（充其量）或扼杀他们的创造力（最坏的情况下）。

我还建议简化编码标准，并且在大多数情况下，告诉您的开发人员不应该做什么，而不是提供他们应该 em>做。找到他们合理认同的东西（比如“避免像瘟疫一样使用空的捕获块，因为它们只是掩盖了错误”）。让他们知道他们是开发标准的受益者，以获得大多数人的支持。

急于解雇非柔韧的员工不是答案。将此转化为开发者的积极体验，每个人都获胜。

Answer 14

  

编辑：大概只有​​10个   我团队中的开发人员。他们结束了   加压，不要花时间   放置评论并巧妙地完成代码   因为压力更大   完成我们的产品   管理。什么是解决方案   对此？

根据我的经验，需要一个非常强大的个人来“培训”高层管理人员，了解软件开发的实际工作方式并与之相抗衡。很明显，你对自己的处境感到非常沮丧，但不幸的是，你可能无法修复。您可能无法获得所需的资源或合作。我曾在这种环境中工作，我的解决方案是找另一份工作。

Answer 15

编码指南很重要，但请注意不要：

• 太迂腐了。易于遵循/易于记忆的规则是好的。公共（例如：对您的客户）接口标准是好的。如果必须将内部变量调用为num_of_elements或number_of_elements或nelem，则强制执行。
• 从标准化步入他们的创造力。例如，决定禁止单身人士是太多了。作为一名程序员与成为一名艺术家并没有什么不同。你必须留下一定程度的创造力。

另外：

• 进行同行评审。当开发人员提交一些代码时，另一位开发人员必须在编码标准方面对其进行审核并批准。如果找到了错误，你就不会责怪一个人，这从来都不是好事，但是你把错误的可能性分成了两个（愿意或不愿意）的开发人员。
• 如果您是经理，请找时间执行此审核，甚至是使用它们编写代码。一个好的经理是团队的一部分，并分担其任务和负担。如果你只是一个“邮件，文件和订单”类型的经理，你将不会得到你的团队的尊重，特别是如果由爱好者制作，而不是盲目打字的猴子。如同您是一位经验丰富的团队成员一样，请随身携带。

Answer 16

在我担任团队领导并获得报酬之前，我不会担心这件事。如果他编写了糟糕的代码，让它成为你自己做的事情，你可能没有足够的报酬来担心它。

Answer 17

您可以尝试向他们提供徽章和声望点。 ;）

说真的，也许某种“金星/皱眉脸”系统可以通过彼此的竞争来激励他们，也许可以减轻一点情绪......我实际上并不是说给他们金星或皱眉面孔，因为这将是愚蠢的。只是一些一般的奖励制度。

Answer 18

我首先回答一下你的问题：“我怎样才能说服开发人员遵循编码标准会让他们的生活更美好？”

答案中至少有两个部分：

1. 作为倡导者，举证责任在于：如果您无法解释为什么采用这些标准会以可衡量的方式改善生活，那么您的编码标准就不值得采用。这是您的主要绊脚石：您已经有一个雇用人员从事工作的组织，因此业务显然已经取得了一些成功。您的标准如何让事情变得更好？你的答案应该用美元或人们的生活时间表示（在工作场所实际上是相同的。）

2. 简单性更好。如果您的标准文档是长页面，繁忙的开发人员将立即忽略它。在我的世界里，最好的文件只不过一页。对于编码标准，我倾向于创建一张示例代码。如果我已成功完成上述业务案例，我会告诉团队，“请让您的代码看起来像这样。”

如果你在这次讨论中犯了更多高级管理层的错误，那么第1点就更为重要。在准确了解您的编码标准将为组织节省多少美元时，它们将会出乎意料地残酷。如果仔细考虑，你可以赢得这个论点：例如，减少调试时间可以减少每小时的成本，因为人们可以快速检查错误列表。那是现金的节省。

如果您犯了威胁工程师的错误（例如，上述终止的建议），那么您很有可能最终会出现在每日WTF上。

如果您能够在第1点和第2点取得成功，那么对标准验证的实际支持已经很好理解。确保尽可能在IDE中处理（control-shift-F格式正确等），自动检查工具等。

技术方法很容易。人民的问题总是最困难的（也是最重要的）。

Answer 19

听起来你不是他们的经理。如果没有，您需要做的第一件事就是获得管理层的支持。让开发经理将开发人员对标准的遵守情况整合到员工评审中。您应该有足够的数据点将这个概念出售给您的老板......编码标准的好处在网上有很好的记录。

其次，开发人员自己对编码标准有一些输入是很重要的。否则，感觉就像你在真空中规定标准。如果开发人员对公司的编码指南有什么说法，他们就更容易遵循它。

最后，使用之前答案中提到的自动化工具会使代码审查不那么痛苦，因为您至少可以期望遵守法规。

Answer 20

您应该在高级开发人员审核其他开发人员的代码时进行代码审查。如果他们不遵守惯例，他们将无法通过代码审查，也不会进入存储库。

这需要一些人工工程，因为它比基于软件更基于流程。

哦，紧迫的截止日期不是坏代码的借口。作为程序员，我们的工作是编写可由团队其他成员维护的可靠质量代码。

Answer 21

也许你的标准限制太多，编码标准很好但有时候更少。给他们一个关于他们的代码应该如何看待的页面摘要，做代码审查并使那些不符合标准的代码失败。我也喜欢自动化的建议。

向他们解释为什么编码标准是一件好事。

我在Visual Studio中使用Code Style enforcer，eclipse强制执行编码标准。

http://joel.fjorden.se/static.php?page=CodeStyleEnforcer

Answer 22

我同意乔。作为持续集成过程的一部分，尽可能多地自动化。更容易遵守而不失去手头任务的重点（编程），人们将遵守更多。

Answer 23

自动化可能是解决问题的最佳方法，上述fxcop或团队系统解决方案运行良好。

这里可能还有另一个问题，我知道当我还是一名初级开发者时，我被交给了一个巨大的编码标准文档并要求建立一切以匹配它。我记得被大量的物品所淹没，我显然不记得这么做了，特别是在试图让一些工作到最后期限的时候......

如果您的标准很冗长，那么可能值得挑选出您最希望看到的项目并将注意力集中在那些项目上，然后逐渐逐步进入其他项目，它可能比期望它们改变所有不良习惯更好。一次。

Answer 24

我被指责负责在公司内部推行标准。 我学到了许多有用的东西和一些课程。遵循这些标准的开发社区大约有25个。 首先要确定的是标准的文化和胃口，因为这将决定你的方法。您需要的第一件事就是管理层支持。可能有项目经理对标准的唯一看法是认为他们有助于缩短最后期限。从根本上说，您需要高级技术经理的支持，他们认识到代码审查和标准是解决“技术债务”的基本工具。有许多理由和资源可以描述这一点，但对于拥有大量遗留代码库的任何组织来说，这都是一个巨大的挑战。

如果技术债务存在问题，那么您的组织就已经存在开发时间表，测试，新兴支持积压以及可能的高员工流动等问题。如果您需要强调高级管理层面临的挑战，那么这些都应该可以量化（大致）。

你需要说服的下一个人是开发者本身。你会有一些积极的人和一些反对的人。在我们公司，我们组建了一个“标准”小组，并邀请了一些开发人员参与其中。在引入标准文件时，标准组在讨论之前对其进行了讨论并达成了一致意见。

我们发现传达包容性和积极的信息非常重要。 “我们”将会这样做，而不是“你”必须这样做。诸如“标准将帮助我们所有人学习更多，并使我们的生活更长远”这样的陈述也有帮助。将标准作为学习和学习新技能的工具（您将会一直这样）。

关闭标准的背面是正式的代码审查。这样做的过程很可能是根据您组织的个人需求量身定制的，但最重要的是要认为代码审查不是批评。同样重要的是不要将个人表现与他们所拥有的失败的代码审查数量联系起来。关于他们支持这一进程的一般意愿的一般观察应该足够了。

在我们的组织中，标准的后期引入（特别是在早期）发现它们相当流畅且易于变化（因为我们更多地了解它们的相关性和适用性），因此我们遇到了将变更传达给开发的问题社区。我们举办培训日和简报会，而不是为了让开发人员闲暇时阅读文件。这些时候开发人员远离他们的办公桌，并帮助个人觉得他们有机会挑战和质疑。在这些培训课程中，我们还提出了新的技术和想法，并传达了“这非常有用，它将使我们的生活更轻松”的信息。

我们会定期举行标准审核会议，让每个人都可以反馈他们认为有效和无效的方式。这一切都传达了开发人员没有被指示的信息，而长期来看，我们只是想让他们的生活更轻松。当然，对标准和最佳实践（以及参与其中）的良好掌握对任何人的简历都会很好看！

对时间尺度的任何估计都应该考虑代码审查，管理层应该认识到，在标准出台后，至少在短时间内，“产出”可能会下降。

你所获得的任何阻力几乎肯定都是被动的，人们会拒绝遵循标准或代码审查。这很难处理（如果你对他们友好，有时可能会感到不愉快）。如果您有足够的系统来记录代码审查和参与，那么您将有一些指标用于提供绩效评估（尽管我只是提倡这作为最后的手段）。这是您的管理层支持最重要的地方。

最后，会出现这样的情况：当筹码出现故障时，我们必须低头而且代码就像疯了一样。这些经常看到标准出来了。这里要做的重要事情是将标准和评论嵌入到您的流程中，这是不可能的。

我可能会写一篇关于此的文章，并详细介绍。我希望上述内容是有道理的，因为它是一个大脑转储！

Answer 25

将其作为年度评审工作描述的一部分，如果成功，则将其与年度奖金联系起来。

Answer 26

给他们自己（彼此的）旧代码来修复，扩展，维护，修改，重构，优化等等。最好是来自多个其他代码的每几段代码。

请求报告他们必须使用的代码质量。

将报告交给代码的原作者。

Answer 27

我可能间接地攻击某种的问题。而不是指向他的代码并说它需要变得更好（或者那个顺序上的东西），你可以回到你应该做的事情的规范。它可能已经有违反要求（或至少是指导方针）;如果是这样的话，你有一个真实的基础来说明他正在做的事情并不是。

如果它还没有包含任何此类要求，取决于规范的流畅程度，您可能会努力获得一些此类要求（或至少是指南）。

另一种可能性是考虑一系列公司范围的编码指南。如果已经有一个，他可能违反了它的要求。如果是这样，你（再次）有一个真实的基础，说他需要改变他的方式。如果已经有不，那么您可以考虑尝试将其中一个放置到位。

就像总有至少一个编写糟糕工作的程序员一样，至少对官僚来说也是如此，他们会欢迎更多的规则和规定。有点看，你几乎可以肯定找到至少一个这样的。机会非常好，你可以找到这样的人，使得至少在一定程度上合理的指导方针属于他的责任范围。

向他提出一个建议（完全不直接提及当前的问题），该公司确实应该有一套关于如何完成编码的指南。销售此类产品的一种方法是提及ISO 9000（及相关）标准，并指出这些 最佳做法，即使他们不打算获得认证符合标准。

做好准备：当你这样做时，你几乎肯定会（有效地）自愿参与制定指南。如果你足够初级，他们可能会决定正式让其他人负责，但他们可能会把它看成是“你的想法”，所以你很可能仍然会做大部分的工作。既然如此，如果你要走这条路，那就做好“真实”的准备。如果你确实制定了公司范围的指南，那么你真的需要考虑整个公司的适用范围，而不仅仅是处理你对有关人员编码的烦恼。

另外请注意，这种事情会对你的职业生涯产生重大影响 - 如果你最想要的是成为一个坐在他的小隔间里而被单独留下来制作代码的人，这可能不是一个好主意。它几乎肯定会让你更加明显，并且作为一个或多或少管理类型的人，而不仅仅是一个程序员（当你移动时，这很可能会跟随你到你的下一份工作）。这并不总是坏事，但你需要考虑这是否是你真正想要的。

Answer 28

http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

http://psycnet.apa.org/?fa=main.doiLanding&doi=10.1037/0022-3514.77.6.1121

也解释了为什么大多数司机认为自己是平均值。基本问题是要准确评估自己的能力，你需要足够胜任。最不称职的人也最不了解他们缺乏的技能。

在你的位置上我也会考虑上面的一些建议。

Answer 29

你是否尝试过指节间的木尺？在学校为我工作：P

但是，严肃地说，如果没有遵循标准，你就可以遵循标准，并且你可以接受培训和纪律处分，然后遵循纪律程序。如果你不是，并且你不能说服你的高层应该遵循这个，那么你似乎有两个选择：

• 吸收它并充分利用它
• 开始寻找其他工作

Answer 30

员工？在这里 - 我把这些人送到人力资源部门，讨论职业道德，威胁终止。

以下标准不是可选的。作为员工 - 或承包商 - 必须遵循编码样式。不这样做，故意违反合同。包括让他们支付外部顾问来清理乱七八糟的东西。包括 - 重复 - 终止违反合同。

这很简单 - 如果我雇佣你作为我的团队的程序员，而你不遵守命令并让自己对团队无能为力，那么你就没有权利加入这个团队。

Answer 31

使用智能代码格式化程序和可能的分析工具来检查是否遵循标准。

使用一些会话来介绍标准。

为每个月最符合标准的程序员提供一种奖励。

如果一切都失败了，就摆脱它们。

Answer 32

根据我的经验，人们不遵守标准，因为他们不了解或不关心它。有时候，编码标准很难传达，即使它们是新的并被认为是重要的。

这类问题应该通过

来解决

• 的训练
• 的通信
• 的评价

如果人们不听，团队领导应该关心它，并帮助强制指导认真。

Answer 33

首先，每个人都尊重退伍军人认可的编码敏感编码标准。不要将这份工作交给那些对编程一无所知或者想要执行他/她在互联网上找到的第一份文件的MBA质量保证人员。最重要的是，收集团队中每个人的意见和建议。

接下来，请注意，没有人会阅读该文档。对于我们大多数人来说，不仅编码风格是一种宗教问题，我们还是有太多东西无法读取并且通常会拖延这个问题。

最好的方法是让它成为建筑过程的一部分。如果代码没有编译，程序员就会修复它。如果他们必须做更多的点击...你也可以有一个预提交脚本（svn有那些预挂钩）。基本上，这是一个可以自动化的过程，这是每个人都避免手动做的事情。

然而！请注意：

• 如果该工具正在强制执行其他操作 风格（配置错误）
• 列表项

遗留代码

Answer 34

每个开发人员都有自己的编程风格，基于他在各种语言或各种工作环境中的经验。每个人都基于许多因素发展自己的风格。你不能让某人遵循严格的编码指南。

一个可能的解决方案，尽管成功率有限，但是收集并讨论要求，从他们自己的风格中获取反馈并尝试查找这些之间的妥协。尝试向上级或那些为您公司编制编码标准的人提交此妥协方案。

此外，开发人员应该被告知编码标准化的重要性，而不是强迫他们采用您的标准，并阅读整个页面，了解他们应该如何编写代码。沟通是解决问题和解决问题的最佳方式。没有沟通，只会出现混乱。

如上所述，您还可以在修订之前尝试使用代码样式格式化程序。

Answer 35

通过强制执行基于编码标准文档的代码审查，并在未遵循编码标准的情况下拒绝，并在标准构建过程中包含代码美化器（http://sourceforge.net/projects/gcgreatcode）。在完全编译之后（没有错误，没有编译器警告，没有lint警告，..）调用greatcode。

Answer 36

召开会议讨论与编码标准实施相关的要点的利弊。从每个同行那里得到不同意见并过滤掉所有建议。

传达遵循标准及其益处的重要性，以完全理解它们。

让它们成为一种习惯。

Answer 37

只是告诉他们这样做，说你的方式是正确的方式保证失败。几乎100％保证它会失败。我没有看到任何例外。 （你可以引用尽可能多的书籍和网站以及关于这个主题的专家，结果是一样的）

根据公司的年龄，工程师的动力是什么使公司成为现实，所以如果他们遵循这种势头，他们就是以正确的方式做事。

如果你想成功

1）你必须有大量买入，这意味着该小组必须处理解决方案而不是被指示

2）大的改变将失败，如果公司已经存在足够长的时间你必须进行抛光，而不是重新开始。只进行一些小调整，一次或两次调整。如果你成功了，那么你可以尝试另一个，如果你失败然后放弃......当在罗马......

如果它困扰你这么多，那么也许你在错误的工作或错误的公司的正确工作。

标准，过程等通常与堕胎和宗教一样敏感，你越多，他们越深入，你就越不可能取得任何进展。

使用或引用时尚如tqm，cmm，5s，iso，six sigma等是失败的秘诀。现在成为一家从公司到公司的承包商，教会那些让你变得富有的时尚，或许你应该研究一下。

如果没有团队这样做，那么团队中就没有我，那么你就会失败。获得管理层购买而非团队购买导致叛变，然后失败或裁员和失败或罢工和失败，失去关键员工和失败。你必须加入他们而不是打他们，此时你必须撤消你已经拥有的战斗，这将是一场上山战。

Answer 38

在没有更多信息的情况下很难将这样的事情搞得一团糟，但根据我的经验，我看到人们出于多种原因偏离了既定的代码标准。

以下是一些常见原因：

• 截止日期不断变化导致technical debt（转移目标帖子），
• '刚刚完成'心态（通常由管理层驱动）
• 缺乏同行评审
• 缺乏责任
• 关于编码标准或标准的分歧过于细化/限制
• 标准不够清晰或不正确理解

你的第一步应该是尝试理解为什么人们没有遵循标准，然后再找出执行方法 - 如果这是第三个项目，那么显然有些问题是不容易解决的。

在一天结束时，你需要能够证明执行标准的成本（时间/精力） - 即如果标准是非常精细的，那么它比更宽松的标准更昂贵。

其次，如果您希望人们认真对待他们，您需要在公司内部拥有一些影响力来强制执行标准。您可能需要举例说明不遵守商定标准的人（见下文）。

最后，您确实需要寻求开发团队的意见，无论您认为他们是否经验丰富。如果有的话，你真的需要能够通过说你给每个人提供反馈和输入的机会来证明编码标准的合理性 - 即它是一个商定的标准。

Answer 39

虽然我完全同意自动化您的标准，但我真的很好奇您公司的标准是什么，以及这里有多少人会做与您的开发人员完全相同的事情。

我曾与那些输入他们认为是标准的完整文件的人一起工作，并试图将他们传递给他们的同事。这是他们失败的地方：

1. 他们在泡沫中创造了它们。没有征询团队的意见。
2. 他们是基于我们没有使用的语言。
3. 大多数规则都有基础 最被认为是一个缺陷。 “如果 你有一个很大的方法/类“是一个 变量前缀的理由; 为什么不只是小 方法/类而不用担心 你在命名什么？
4. 评论方法基于 他们的学术规则。过于 详细功能标题等。
5. 他们专注于错误的事情。这些主要集中在变量，方法和类的命名上，因此它们将遵循某种形式（某些前缀）而不是内容 - “它们是否准确地说明了它们是什么/做什么？”是唯一一个与命名有关的问题（除了它所做的语言......）。
6. 他们只是没有影响力 人们要关心。

您最好的选择是每周进行一次代码审核会议，然后按照屏幕上的标准添加 您的 代码并获得同事的批评。你会看到你的标准失败的地方，并在你面前获得“好”的代码。看到行动中的良好实践应该影响未来的决策。

准备好谦卑 - 问题可能就是你。

Answer 40

说话，说话，和他们交谈，我想如果你知道这是一个优秀的程序员，你就不能放弃他/她。 你写代码的方式不容易，当你更担心写下你的想法时，很容易忘记新标准。

Answer 41

在查看您在SO上提出的问题时，我会说您的开发人员遇到了接受问题。你不应该被视为应该告诉高级开发人员如何开展工作的人。

因此，专注于需要而不是如何。他们应该能够理解编码标准很重要。但它应该是他们的标准，而不是你的标准。让他们下定决心，确保他们有足够的时间谈论他们并做出决定，然后写下他们的决定。然后，当他们不遵守标准时，你可以做一些事情。

[编辑] 替换或教育管理层。管理层并不关心，所以他们为什么要这样做。