Answers:
每个要求的原因。这样，遵循该标准就不会成为某种形式的货物崇拜，并且人们知道，如果不再使用该标准的原因，可以更改该标准，或者在理由显然不适用的特定情况下违反该标准。
制表符与空格！当我的一位同事不小心将很多标签提交到空间转移到存储库时，我得到了疯狂的更新
命名约定
编辑：这是指命名准则，而不是命名规则。
例如，准则为All boolean values should begin with Is/Can/Has/etc when possible。一条规则是All boolean values must start with Is
IsCanUpdate和的属性IsHasChildren。当然，这是错误的，但是它是标准中的一项法令。这就是我的观点：一旦开始指定这些内容，就必须确保涵盖所有基础，否则人们会遇到标准未涵盖或覆盖不清的内容，然后他们写错了内容，或他们开始忽略标准。无论哪种方式，球队都会输。
组的编码标准应包括必须解决的警告和错误的编译器选项。
程序员应该可以自由地为自己的代码增加警告，但是必须有一个基线，以便阅读和使用他人的代码不会使您从编译器获得的输出混乱。
这样的标准还必须解决程序员应该如何逐案禁用此类警告的情况，如果有例外的代码片段否则将不符合要求。
编码标准帮助，当你编写代码的第一次一点，他们帮助很大 ，当你或你的更换，有2年后更新代码。
理想的标准导致出现代码，您可以在其中跳转到代码中的任意页面，并在第一次通读时确切地了解它的作用，因为
另一方面，太多的任意标准会破坏编写代码的流程。因此，我认为应根据以下两个标准对提议的编码约定中的每个项目进行评估：
如果都不正确，则该项目只是任意的，可能不必要
我将在编写的标准中包括以下内容：
为清晰起见：
文件组织：为文件中的项目指定固定顺序，可使团队轻松浏览其他文件。您不必去寻找#defines或结构定义。
命名约定：一致的命名有助于可读性。但是，避免过多指定太多规则，这会损害可写性。
代码结构。Curly Brace的位置，缩进级别，空格与制表符等。是的，这可能是个人的强烈偏爱，但目标是明确的代码。为团队找到最佳选择，并坚持下去。
正确性：
针对您的问题类型的最佳实践：有关内存分配，并发性或可移植性的规则。
“常量Correctnesss”，正确使用static和volatile等。
有关预处理器宏的规则，以及该语言的其他容易滥用的功能。
使人思考的鼓舞人心，务实的想法，而不是阻止人们思考的消极限制。
否则，您将得到代码猴子，他们害怕去追赶香蕉。
一些良好的旧常识不会出错。太多的编码标准文档都在无关紧要的方面进行工作（字体类型和大小等项目是我所见过的更极端的项目之一）。
如果您在一组开发人员中，最好的做法是互相交谈并查看代码，就可以接受的内容达成共识，以及是否需要将要点写下来作为准则，但要保留它们作为准则。只是那个准则。如果您无法证明与指南之间存在任何差异，那么您应该考虑为什么这样做。
归根结底，清晰易懂的代码比对布局或版式的任何严格规定更为重要。
正如其他人提到的那样，代码测试的覆盖范围很重要。我也喜欢看：
项目结构。测试是代码的一部分，还是在单独的项目/程序包/目录中？UI代码是否与后端内容一起使用？如果没有，如何分隔？
开发过程。在代码之前编写测试？修复损坏的构建优先于开发吗？什么时候进行代码审阅，应涵盖哪些内容？
源代码管理。什么时候检入？设计文档和测试计划是否受版本控制？您什么时候分支，什么时候标记？您是否保留以前的版本，如果保留，则保留多少/持续多长时间？
部署标准。如何打包构建？发行说明需要什么？如何创建/控制/运行升级脚本？
忘记所有有关命名约定，格式以及函数/方法/模块中可以包含多少行的内容。一条规则：在编辑的内容中使用现有样式。如果您不喜欢某人的样式，请在代码审查中加以区分。唯一的例外可能是tabs-vs-spaces，这仅仅是因为许多编辑器/ IDE会盲目地将它们转换为另一种，然后由于每一行都被更改而最终破坏了更改历史记录。
我认为实际上有两件事需要解决，实际上我会分开考虑它们，因为虽然我认为两者都很重要，但无法以相同的方式进行处理。
我在技术方面符合编码标准，包括Herb Sutter和Andrei Alexandrescu及其C ++编码标准。我符合编码风格的演示，其中包括命名约定，缩进等。
编码标准
因为它纯粹是技术性的，所以编码标准几乎可以是客观的。因此，每条规则都应有理由支持。我在书中提到的每个项目都有：
基本原理和异常非常重要，因为它们概述了原因和时间。
标题应足够明确，以使得在评审过程中，只需要列出要使用的标题（备忘单）即可。显然，按类别对项目进行分组以使其更容易查找。
即使C ++被认为是毛茸茸的，Sutter和Alexandrescu仍然只能列出一百个项目；）
编码风格
这部分通常不太客观（可以是完全主观的）。这里的目的是保证一致性，因为这有助于维护人员和新手。
您不想在这里进入哪个缩进或大括号样式更好的圣战，为此有论坛：因此在此类别中，您通过共识>多数投票>领导人的任意决定来做事。
有关格式的示例，请参见“ 艺术风格”的选项列表。理想情况下，规则应该清晰，完整，以使程序可以重写代码（尽管不太可能会编写一个;））
对于命名约定，我将尝试使类/类型与变量/属性容易区分开。
我也在此类别中将“度量”分类为：
杂项？
最后，在编码标准中很少讨论（如果有的话）一项，也许是因为它对于每个应用程序来说都是特定的：代码组织。架构问题也许是最突出的问题，将最初的设计搞砸了，从现在开始，您将为之困扰。您也许应该添加一个用于基本文件处理的部分：公共/私有头，依赖项管理，关注点分离，与其他系统或库的接口...
但是，如果它们没有被实际应用和执行，那将什么都不是。
任何违规行为都应在代码审查期间提出，并且如果未解决违规行为，则不能进行代码审查：
显然，改变规则意味着要从领导者那里“走出去”。
我喜欢《框架设计指南》中的格式，它包括一个概述部分和该指南的基本原理。最有用的部分是从“执行”，“请勿”，“避免”和“考虑”开始的细节。
这是“ 实现接口成员 ”部分中的一个示例，它明确包含以下内容（请注意，为求简单，我放弃了基本原理）
避免在没有充分理由的情况下显式实现接口成员
如果仅通过接口调用成员，则考虑显式实现接口成员。
不要将显式成员用作安全边界。
请提供一个受保护的虚拟成员，它提供了相同的功能>明确执行成员，如果该功能是指由派生类专业。
这会产生良好的总体音调。通过使用“避免并考虑”，您可以允许开发人员使用他们的判断。另外，由于它们只是准则而非规则，因此开发人员可能会发现它们更可口，从而更有可能遵循它们。
编码标准实际上是以下几项：
编码约定
最佳实践
对于前。 尝试后绝不留空渔获
try { Foo(); } catch { //do nothing }
1）如果Foo（）抛出异常，则可能导致后面的函数出现其他问题（假定foo成功）。
2）全局错误处理程序在产品上发生异常时不会通知支持团队异常
编码环境
当写在纸上的编码标准非常有效时。我喜欢Go发布其编码标准的方式。它具有将gofmt程序文本格式化为格式的工具。关于编码格式的任何辩论都将仅仅是对以下来源的补丁gofmt。
至于格式应该是什么，
if，函数主体，语句块是否出于任何其他目的，当我阅读别人的（主要是C语言）代码时，如果变量/函数名称在项目上下文中不直观，或者超过五个缩进级别，或者函数采用了六个或七个以上的参数，或者函数运行超过屏幕上只有两三页，阅读和理解代码变得非常困难。当要求对其进行增强/维护工作时，只会增加难度。这让我希望gofmt为每个项目（甚至语言）编写程序，并在将每个程序提交到项目之前通过该程序运行每个源代码文件。
它的指南简明扼要，但如果需要，则提供了详细信息。