组织中的编码风格是可选的吗？

该编程样式文档有一条通用规则，即：

如果强烈反对这些规则，则可能违反这些规则。

这与我的思维方式相冲突，并且有很多文章说编码风格实际上很重要。例如，这说：

编码标准文档告诉开发人员如何编写代码。他们将代替所有开发人员按照自己喜欢的样式进行编码，而是将所有代码编写为文档中概述的标准。这样可以确保以一致的方式对大型项目进行编码-不同的程序员不会以不同的方式编写部分内容。此解决方案不仅使代码更易于理解，而且还确保任何查看该代码的开发人员都将知道整个应用程序的期望。

因此，我是否误解了本文档以及该问题顶部的引文中的内容？人们真的可以忽略编码样式吗？

也许我还不够清楚，所以通过这次编辑，我将澄清一下。

我正在为我们的团队编写编码样式文档，我想使用一些静态分析器检查样式。如果失败，詹金斯将发送电子邮件。如果样式不匹配，我想使代码审查失败。这显然与第一个引用冲突。

但是，如果引用正确，那么如果任何人都可以做自己想做的事情，那么编码样式文档的用途是什么？

据我所知，令您感到困惑的陈述是务实的折衷，目的是为了使准则能尽可能地广泛地服务于广大受众。根据您的特定上下文（下面有更多内容），您可以选择调整它并更有效地使用指南。

您会看到，准则指的是“强烈的个人异议”，以此作为证明违法的理由。此类异议不可轻视，特别是如果这些异议来自经验丰富的开发人员。

请注意，这些异议可能是错误的，但是（这是非常大的错误）它们还可能表明某条特定规则是错误的-无论是在一般情况下还是在特定项目的上下文中（一个规则不匹配的示例都是要求提供详细记录性能关键代码）。

我认为任何明智的风格指南都应考虑到上述因素，并尝试适应可能的调整需求。现在，如果让您感到困惑的指南仅针对具有高效，流畅的流程和环境的成熟团队，那么可以说得不太含糊，例如：

应当严格遵守规则，除非对它们提出质疑-在这种情况下，应通过忽略挑战或接受挑战并调整规则以使其适应，直到被解决之前，被质疑的规则都应被忽略。

您可能会更喜欢上面的方法，并且希望对所有人来说，它在任何地方都一样，但是请仔细研究一下“提出挑战/保持忽略/调整”这一部分，并问自己如何实现。问问自己，要花多长时间取决于项目和团队。如果要花一个小时，可以接受吗？如果要花一天或一周或一个月的时间怎么办？

您会发现，如果提出挑战和忽略直到解决的方法，它可以为任何项目提供指导，从而为滥用提供了广阔的大门。“是的，我们听到了，按照指南的说明进行操作。首先，填写此挑战表并获得CEO / CFO / CTO的批准；预计这需要一两个星期。在此之后，请等待直到我们更新代码检查；这可能需要一两周的时间。同时，请确保您的性能关键代码对每次寄存器移动都吐出格式正确的日志记录语句。”

我看不懂指南作者的想法，但是合理的假设是，他们希望避免如上所述使用它来证明一团糟。从这个角度来看，更清楚地声明该指南不承担任何执行力是绝对安全的-这样，尽管笨拙，仍然可以将其用于任意范围的团队和项目。可能期望如此宽泛的配额会给更成熟，效率更高的团队提供机会，在不损害开发人员生产力的情况下合理缩小范围。

根据您的具体情况，为您的团队编写编码样式文档，如果样式不匹配，则代码审查失败-我认为您需要弄清楚开发人员挑战特定规则可能需要多长时间，而忽略它，解决，并根据分辨率对其进行更改或恢复。

如果您想出一种使该过程正常进行而又不给开发工作流程带来任何障碍的方法，那么确实值得考虑采用一种正规且易于跟踪的挑战/解决方案，而不是混乱的“如果您哭得足够大就违背”。

附带说明一下，我想谈谈您在另一条评论中写的内容：“假设编码风格是理想的，如果不是这样的话。”

确实，这是一个危险的假设。我对它不屑一顾（两次！在一个项目中！我有丰富的经验，并想像自己对此有所了解，请尝试一下），我强烈建议您放弃它。较为安全的做法是假设样式指南中可能有错误，并在考虑发现此类错误的情况下竭尽所能。

允许人们由于个人喜好而忽略编码风格是一个坏主意。

您问题中的引号似乎允许任何开发人员简单地说：“我不会使用这种样式，因为我不喜欢它。”

这与整个观点背道而驰，这使团队中的每个人都以相同的方式做事，以保持一致性和可读性。

我同意带有这样声明的样式文档可能毫无意义。

但是，建议在遵循样式准则时要有一些灵活性：

• 严格遵循准则可能会阻止编写特定代码的最佳方法。开发人员应该能够忽略该准则，并证明他们所做的事情是在这种情况下完成某事的最佳，最易读的方法。
• 使用旧代码可能需要灵活性。 重新设计现有的大型代码库可能不是很好的利用时间。如果您大量重写了特定的部分，则可以将其重新格式化为首选样式。但是，如果只做很小的更改，最好使用代码的现有样式。
• 仔细检查每一次对样式指南的小违规，都不是浪费时间。 代码审查是突出显示与团队风格明显不符的任何代码的好时机。但是，捕捉和修复小风格的“错误”可能会成为忙于处理错误事物的工作。当然，如果公然忽略了样式，则代码审查失败。但是我不喜欢运行分析器并指出每个放错位置的括号或缩进的想法，不要介意在此基础上使某人失败。

总结：可以灵活地遵循样式准则，以最好地满足团队的需求，但不能出于个人喜好等任意原因。

编码样式和样式指南可帮助使代码更具可读性。存在可读性以帮助提高复杂性。

因此，最终是否违反（我称其为适应）编码风格以适应您的组织需求，最终取决于它在多大程度上有助于使事情易于理解。

记住，从OO编程到函数范式，再到各种并发模型，一切，我强调，一切都是为了帮助人们处理复杂性而存在的。

任何傻瓜都可以编写计算机可以理解的代码。好的程序员编写人类可以理解的代码。-马丁·福勒（Martin Fowler），2008年

组织中的编码风格是可选的吗？

组织选择使用编码样式-不需要首先使用。

因此，您正在阅读的引言解决了我在编码“样式”和真正的超级巨星“黑客”方面遇到的最大问题-您带了一个新手，他编写了将丢下僵尸并使他人的旧服务器快速尖叫的代码。 .. 但他的编码风格与您的“公认的组织风格”不同。他拒绝更改，并且使每个人都符合他的特定样式的过程将既耗时又昂贵。怎么办？

我认识的大多数超级黑客都具有与自己的技能一样大的自我意识，他们希望组织适应他们，而不是反过来。因此，也许您的编码风格标准应该更像是一种编码风格指南，以便您可以让这个杀手级的黑客家伙以某种风格上的偏差继续编写出快速而惊人的代码，但是请确保其他人都明白这一点，直到他们到达他的史诗般的黑客手中为止身份，他们需要遵守规则（甚至在他之后帮助清理）。

当然，这是管理方面的噩梦，但是管理技术人员通常总有点像放牧猫。因此，大多数公司都具有“样式准则”而不是“样式标准”。而且由于所有公司都违反样式，因此构建不会失败，代码审查也不会自动失败。您可以决定要解决的管理问题-允许超级巨星黑客并拥有“准则”，或者失去超级巨星并拥有更一致的代码样式。

因此，我是否误解了本文档以及该问题顶部的引文中的内容？人们真的可以忽略编码样式吗？

这取决于。

我现在所在的位置尚无样式指南，也没什么大不了的。程序员之间有一些细微的差异，但不会以任何有意义的方式影响可读性，可发现性或一致性。而且我们有一个足够大的组和足够强大的文化来执行，任何新成员的团队将下降线（或其他）。

在以前的公司中，我们发展迅速，有些人对语言及其习语不熟悉。在那家公司，大量的人涌入意味着没有一种文化要求良好的写作。刚接触该语言的人员意味着有很多需要调整的地方。有自动化的风格检查都做了调整的最有效的方式，与实际写入的导游是培养出新的人在我们的预期的最佳方式。

就个人而言，我不太在乎样式指南，甚至不在乎自动样式执行。如果这个人甚至连基本的习惯用法都没有，那么为什么要雇用他们作为程序员呢？如果他们是一个糟糕的团队合作者，以至于他们会不断编写其他人难以使用的代码，那么为什么要雇用他们呢？

这更多是一种心理策略，而不是对如何最好地管理编码样式的字面解释。它使团队/公司/经理/领导者的专制性降低。我将更多地关注情境例外，而不是个人例外。不管编码文档如何，目标都是使事情易于阅读。如果认为有必要，应解决混乱的代码并进行更改。有很多工具可以处理这些乏味的小事情，因此请使用它们。

每个规则都有例外。给人们“一些”摆动空间。每个人参与编码风格规则的参与越少（欢迎新手），他们越愿意反击。许多事情都是黑白的，但有些事情是可以解释的。

目标应该是使每个人都参与编码准则的精神，而不是争夺每个小细节和解释。

是的，有时会出现编码风格文档无法使用的情况，应该允许专业和成人开发人员知道它们之间的区别。

根据您所做的修改，您将瞄准正确的目标。

使用样式指南有很多好处，但是在我看来，最重要的两个是团队成员之间代码的可读性，以及缺乏“愚蠢的”提交（例如仅空格，或多余的行等）。

为了实现您的目标，您选择（或创建）的样式指南应该简单易行。尝试真正专注于您的需求。没有人喜欢回去重写大量的代码样本，只是为了使lint高兴。但是仍然会有一些好处。

确保您的团队成员批准了样式指南。您要让他们坚持下去，确保他们同意，否则这将是永恒的斗争。

确保样式冲突是“警告”而不是“失败”，让人们来决定样式冲突是否失败。这样做的原因是简单的。我相信工作流程很简单。如果在“测试”阶段的某个地方发生“失败”，那么您将无法进行生产。我使用是为了安全。即使是热修复程序，也必须经过测试阶段（尽管较短）。您是否真的可以说您不会将关键的错误修复推送到生产环境中，因为有人使用“而不是”？使用for循环而不是使用each循环吗？如果for循环在每个循环方面都有改进，该怎么办？是机器（垫料）无法做出的决定，因此，请确保有人为，判断警告，而不是机器引发故障。

至于忽略样式指南，则必须根据具体情况进行判断。确保“偏差”有真实原因。他们会来的。审稿人的工作是确保有充分的理由来解释偏差，而不是琐碎的。

我认为这里的气氛是，如果公认的智慧是编码标准不正确或不完整，那么如果开发人员普遍同意而不是经过艰巨的过程来获得开发者的支持，那就是两个邪恶中较小的一个文档已更改并重新审阅。

还应注意，过去的代码标准实施策略通常不是现在完成工作的方式。

在过去，您只是握着开发人员桌子末端的tom，然后引用章节，并说明为什么他/她的代码违反了34.5.5767节。

现在，我们有了静态代码分析和自动文档编制工具，这些工具消除了许多繁琐的代码标准。

如果所有这些都失败了，您仍然可以将其交还给开发人员，在代码审查中提出，或者如果愿意的话，可以自己进行更改。

您的问题集中在调和两个引号上。我认为treecoder编写的内容通常会回答您的问题。它代表了您在写作风格指南中的指导原则。

更具体地说，由于您负责设置编码样式准则（这是我的假设，因为您是文档编写者），因此您可以决定什么是可选的，以及什么程度可以允许您灵活地使用自己的个人风格球队。您将在必要时获得反馈。但是，一旦制定了指导方针，就应坚持下去。

这样您就可以调和两个看似矛盾的地方：

在准则文档完成之前，请考虑一下作为样式决策者给您的第一句话。如果某种风格标准对您的团队不起作用，那么这将被视为“强烈的个人异议”，您的准则将对此予以反映。

在文档完成之后，请考虑第二个引用给您的团队的报价。为团队设置准则并编写文档后，团队中的所有开发人员都必须遵守样式准则，这一点很重要。

人们拥有哪种编码风格并不重要，只要他们具有编码风格即可。如果一家公司坚持编码风格，那么他们将大举涉足大约49％的开发人员。

问题在于，许多开发人员不介意将自己的编码样式适应公司中的某个普遍标准，但是他们却非常介意那些擅长（或只是更关心）公司政策的人。

这意味着创建编码样式标准可能会浪费大量时间，产生无休止的争论，引起无限的愤慨，并且总体上会浪费大量的时间和精力。

多年来，我一直在努力处理代码样式指南，就像该论坛上的许多其他指南一样。这包括我不喜欢的战斗风格指南，以及试图鼓励其他人使用风格指南来约束自己的风格，以便整体上更具可读性。

公司受益于通用的编码标准。为公司开发软件时，需要考虑许多重要事项，例如我们将如何培训新开发人员以使用上一代代码。在编写代码时，您并不总是在考虑这一点。实际上，许多编码人员甚至选择不考虑其他人在离开后的5年或10年后如何使用该编码。编码风格指南是公司为这5年和10年目标提供关注的一种方法，使开发人员更轻松地处理更大的事情。

另一方面，众所周知，编码风格指南不完善，因为不可能开发出完美的编码风格并将其写下来。实际上，您开始遇到一些有趣的极端情况，如果尝试使其完美，数学证明就会开始失败。因此，我们知道编码样式指南是不完善的。他们可能无法完全专注于我们未来5至10年的需求。

如果我们“强制”使用一种编码样式，那么我们现在将牺牲价值以换取价值。如果我们可以确信我们会从我们的努力中获得回报，那么这将被称为“投资”，但是任何使用编写拙劣的编码风格指南的开发人员都可以证明，这些“可读性”的提高是通过分散开发人员的利益来付出的远离他们的代码。根据我的经验，只有极少数情况下强制编码风格具有优势，通常是针对独特冰河客户的软件，这些软件可以使用30或40年！

相反，我发现将编码风格指南视为宣言是最有效的：“这就是我们认为，对我们小组而言最佳的编码风格。” 这是一堆用文字记录的动荡的想法。“相信”一词很重要：如果信念发生变化，编码风格指南应随之变化。

这就是您的“强烈个人反对”行情出现的地方。在我所说的“完美”世界中，您编写自己认为最好的代码，并承担后果。我们在编程时经常喜欢忽略“软”的后果，但是在这种情况下，它们很重要。如果您不介意我从不给您任何重要且持久的发展，我对您以自己的风格写作没有任何问题。

将整个系统想像成高尔夫球场。编码风格为球道打下了轻松之路。如果您坚持使用编码标准，我们将确保生活尽可能轻松。通过使用自己的编码标准，您越深入入门，就越需要证明自己在团队中的价值。

如果我是星期一早上来的，要发现您花了整个周末来解决我们已经烦恼了一年的问题，而您是按照自己的“特殊”编码标准来完成的，那么我不会告诉您修理它。我要告诉你去洗个澡。如果您的“特殊”编码标准异常“特殊”，我什至建议入门级开发人员“审查”该代码，以传播有关代码工作方式的知识，并毫不客气地提及，如果任何内容看起来难以阅读，他/她都应该整理一下。那个周末，您为公司提供了足够的价值，这甚至不值得一提的是您犯下的严重违反编码标准的行为。

当然，在这个高尔夫比喻中没有界限。如果我要您执行一些排名和文件任务，也许在某些表单中添加新字段，然后您决定利用一些阴暗的字符（如定义宏）来重构整个表单填充代码以适合您的特定样式以及您刚刚从堆栈交换中学到的一些可怕的模板元编程技术，将要求您回去修复它。您选择采取行动，这就是后果。

（免责声明：我已经完全完成了解决一个艰巨任务的这种实现方式is_base_of，并从高级开发人员那里获得了我应得的一切。我说这是值得的。每次我仍然会得到欢乐的笑声看看这种模式如何楔入C ++规范的7个不相关的部分，以实现惊人的效果。高级开发人员，这就是您所不能接受的（这就是您boost为该特定项目所禁止的！）

最好的方法似乎是使用自动代码格式化程序，该代码格式化程序是几乎所有下降IDE的内置功能，并且几乎应存在于几乎任何一种较普遍的编程语言中。这样可以安静地消除代码审查过程中的许多不必要的工作和很多摩擦。

要求所有开发人员养成将格式化程序应用于代码的新创建部分的习惯是完全合理的。

您能做的最糟糕的事情是要求现有的代码格式化程序不支持的某些自定义编码样式。

在很少见的情况下，如果格式化程序确实很难做到某些部分的格式化，但是通常最好对所有人进行格式化，以更好地格式化。

格式化程序可能不支持某些有用的规则（例如，如何命名变量），但如果仅保留这些规则，则相对容易遵循。

实际解决方案（不仅仅是哲学）

允许代码注释覆盖lint，并根据需要编译这些注释的列表（通常与todo注释一样）

使您的开发人员能够明确地，有条理地在惯例之外工作-在人员进行代码审查期间，可以根据需要对其进行检查。