共计 4720 个字符，预计需要花费 12 分钟才能阅读完成。
摘要：不要小看一份编程指南，它真的很有考究……
1、为什么须要编程指南（WHY）
开发人员往往只关注程序的性能是否正确，而漠视品质的其它属性。至于编程指南（或者编程标准），很多程序员更是感觉没有必要遵循：我不恪守这些指南，程序不是执行的也很好吗？
实际上，代码不仅仅是被机器执行的，还是给人看的。不遵循指南的代码，可读性差，不利于了解，因而不利于保护。而软件维护老本通常占整个生命周期老本的 40%~80%。
拥护编程指南的人还可能会提出如下的一些理由：
1）引入编程指南会浪费时间：每个人都有本人的习惯，尤其在编程格局方面。为了合乎指南，破费大量的工夫批改代码格局等，太浪费时间。
刚开始的时候会带来这样的感觉，但长期来看，无论从团队合作还是长期收益来看，遵循指南是十分无益的。能够类比一下交通规则：从个体上看，许多交通规则是十分烦人的，浪费时间。但从群体角度看，这些交通规则不仅能够晋升总体效率，还能够防止交通事故，保障人身安全。许多交通规则，都是在初期引起人们的恶感，但较长一段时间之后，才领会到了它的益处。
2）编程是艺术发明，不能束缚太多：前半句可是算法的上帝 Donald Knuth 讲的。
编程过程具备双重性：宏观上的艺术性，与宏观上的工程性，期间不仅须要有翻新，还须要有束缚。尤其当软件逐渐成为人类文明的载体时，宏观上的工程需要更加重要。共性再显著的程序员，也须要逐渐适应。Python 发明人退出谷歌后，也已经因为代码可读性有余被回绝将代码合入代码库。
3）编程指南自身有意义，但施行太艰难：要让企业中所有的开发人员都齐全把握编程指南，是一件艰难的事件。尤其是企业里的人员通常处于变动状态，总有编程老手继续退出。这给指南的施行带来了十分大的艰难。
近年来，随着代码剖析技术的不断进步，通过代码查看工具主动发现违反编程指南的代码，进而推动编程指南的落实，正在成为一个大趋势。许多公司的施行成果十分显著，大大晋升了代码的品质。
正因为编程指南如此重要，一些大型公司纷纷颁布了编程方面的系列指南。不仅如此，一些行业组织也制订了行业特有的指南。例如：MISRA C 是由汽车产业软件可靠性协会（MISRA：Motor Industry Software Reliability Association）提出的 C 语言开发规范指南，以增进嵌入式零碎的安全性及可移植性。只有合乎 MISRA 指南的软件才能够在汽车畛域进行利用。MISRA C 一开始次要是针对汽车产业，起初许多其余行业也逐步开始应用 MISRA C，包含航空、电信、国防、医疗设施、铁路等畛域中都已有厂商应用 MISRA C。
2、编程指南关注什么（WHAT）
2.1 编程指南内容分类
编程指南次要能够分为两大类：格调类 与编程实际类。
格调类 指南包含标识符的命名、格局以及正文格调等。此类指南疏导开发团队应用对立的代码格调进行开发。统一的编码习惯与格调，会使代码更容易浏览、了解，也更容易保护。须要留神的是，对于开源我的项目，如果在代码格调类指南上有抵触，原则上听从开源我的项目本来的代码格调要求。
• 命名类条款 要求标识符的命名要清晰、明了，含意明确容易了解，软件我的项目外部应具备对立的命名格调。例如驼峰格调的命名是近年来少数企业举荐的命名形式。合乎浏览习惯的命名将明显提高代码可读性，对立的命名格调更加有利于代码的了解和保护。
• 格局类条款 倡议在同一个我的项目中应用对立的排版格局格调，以便所有人都可能轻松的浏览和了解代码，加强代码的可维护性。例如应用空格进行缩进，每次缩进 4 个空格。
• 正文类条款 倡议在须要的时候，对逻辑较为简单或者易于让读者产生困惑的代码，辅以正文加以阐明。正文是为了帮忙阅读者了解代码，所以要从阅读者的角度登程按需正文。例如“代码正文置于对应代码的上方或左边”。正文内容要简洁、明了、无歧义，信息全面而不冗余。正文跟代码一样重要，批改代码时也要保障其相干正文的一致性。只改代码，不改正文是一种不文化行为，毁坏了代码与正文的一致性，让阅读者蛊惑、费解，甚至误会。
编程实际类 指南蕴含编程语言个性相干的条款，比方数据类型、常量与变量的应用，表达式、语句，函数设计与应用，资源管理以及错误处理等。这类编程实际有些具备肯定的时效性，比方语言的新个性。对于趋于成熟的语言新个性，编程指南会疏导开发人员从应用旧个性的编程形式向应用新个性转变，对于这类场景给出最佳实际作为参考，其中疏导、倡议的成分居多。然而，随着工夫的推移，新个性的应用也可能逐渐转变成更加严格的要求条款。编程实际类指南中，健壮性与安全性尤其受到人们的关注。
• 强壮类条款 侧重于晋升软件产品自身的品质属性，比方健壮性、可维护性、运行性能等。这类指南通过在语言自身的语法之外增加额定的正当限度，来防止语言自身或者开发人员无心疏漏导致的意外谬误。比方“”确保枚举常量映射到惟一值”这一条款，尽管编程语言自身可能容许一个枚举中的项具备反复的值，然而这违反了人们对于枚举的天然冀望，而且往往意味着不良的设计，进而导致一些不易发现的谬误。
• 安全类条款 侧重于软件的安全性，次要通过列举可能导致安全隐患的危险场景，联合导致平安危险的示例，要求开发人员防止应用不平安的形式编写代码。比方“禁止内部可控数据作为过程启动函数的参数”这一条款，举例说明了将内部可控输出数据间接传递给过程启动函数，导致程序产生注入破绽。随后给出了如何防止此类危险的多种可行计划，疏导开发人员正确进行平安编码。
2.2 编程指南利用分类
针对不同的场景，每一条编程指南条款的指标、范畴以及适用性都略有不同。总体上来说，编程指南把所有的指南条款分为 准则类 和规定类 两个类别。
准则类条款 通常是对实用于某个较典型的开发场景或语言个性中的一类指南条款的概括，或者是对于不存在明确的规范的场景，给出指导性倡议。比方“标识符命名应合乎浏览习惯”这样的准则，是否合乎浏览习惯是比拟主观，然而尽量让标识符命名有意义，合乎自然语言应用习惯能够极大地提高代码的可读性和可维护性。
规定类条款 是须要听从或参考的比拟具体的优良实际，这类条款通常都具备能够量化的评估伎俩，不便开发人员参照执行。规定类条款又能够细分为两个级别：要求 、 倡议。
• 要求 ：示意开发团队原则上应该听从，违反要求类条款往往会导致软件产品的潜在品质、平安以及可移植性等问题。比方“ 定义宏时，要应用齐备的括号”这条要求条款，如条款所言“宏开展时只做文本替换，在编译时再求值。文本替换后，宏蕴含的语句跟调用点代码合并。合并后的表达式因为操作符的优先级和结合律，可能会导致计算结果跟冀望的不同”。违反此条款往往意味着程序的正确性无奈保障。
• 倡议 ：代码格调类多属于这类条款，除此之外通常示意条款属于最佳实际，有助于进一步升高危险或优化代码。倡议类条款作为优良的实践经验的总结，通常是被广为承受的，但也并非就是惟一的正确抉择，开发团队可联合具体理论状况思考是否驳回。比方“ 行宽不超过 120 个字符”这条倡议条款，从最早的行宽 80 到当初的 120，具体的行宽要求也是适应着开发人员的显示器或编辑器的可显示能力的变动而调整的。具体采纳行宽 80、120 还是其余正当的值都是能够的，具体要看开发团队的理论状况。
3、如何落地编程指南（HOW）
最现实的状况，是所有的开发人员都通过学习，把握了编程指南的内容，而后编写出的代码都合乎指南。但上述场景终归只是个现实。因为开发人员很难齐全把握内容繁冗的编程指南，尤其对于老手，常常会遗记局部指南的内容。这导致他们编写的代码外面不可避免的存在或多或少的违反编程指南的内容。
对于这些违反编程指南的代码，代码检视是发现它们的重要伎俩。能够说，审核代码是否合乎编程指南，是代码检视的核心内容之一。发展代码检视的人员，通常是经验丰富的开发人员，对于指南内容的把握也更加深刻。
对于代码检视人员，其实他们也很难把握指南的全副。尤其是对于资源透露等简单的场景，人工查看效率很低。这时候，主动查看工具就能够施展较大的作用了。当然，局部指南的内容过于抽象，还是须要人工检视人员。例如，相似“标识符命名应合乎浏览习惯”这样的内容，目前工具辨认的准确率还不够高，次要须要依赖检视人员来发现。
3.1 查看工具
基于现有的代码剖析技术，研发人员综合使用语法树、数据流剖析、控制流剖析、指针剖析、符号执行、束缚求解等技术，开发出了许多代码查看工具，以主动地发现违反编程指南等规定的缺点代码。华为公司在长期的代码查看实际过程中，联合研发侧对编程指南落地的诉求，研发了本人的代码查看零碎 CodeCheck（https://www.huaweicloud.com/product/ codecheck.html），并在查看引擎的抉择、研发上积攒了大量的教训和教训。
3.2 查看流程
代码查看工具是否能融洽地集成到开发人员的工作流程中，往往会成为代码查看工具落地的门槛。华为提倡依据开发人员在编码、入库、继续集成阶段对查看速度与能力的要求不同，在不同阶段配置不同的查看规定，以较好地兼顾开发人员对查看工夫与查看能力的要求。
• IDE：编码阶段是最早的缺点查看机会，能够利用 IDE 插件实现查看性能。但因为一些缺点的查看（例如资源泄露）须要对代码进行全量分析能力精确发现，而且耗时很多，因而这个阶段不必对所有的规定进行查看。
• 门禁：在门禁上做查看是最重要的机会。一方面，很难保障所有的开发人员都盲目地在编码阶段进行查看；另一方面，代码一旦通过了门禁，进入了代码库，就成为公司资产的一部分，并可能被大量地复制。这个阶段的查看，也能够被称为“检视机器人”，能够帮忙 Committer 发现一些共性的问题，分担 Committer 的一些低级工作。因为程序员对代码合入工夫比拟敏感，因而，十分耗时的查看规定也不适宜在这里部署。另外，在门禁阶段，便于进行增量式查看，即只查看新写的代码。
• CI：CI(继续集成)因为频率低一些，有些甚至能够放在早晨等非工作工夫，因而对代码查看工夫的容忍度绝对高一些，适宜部署所有的查看规定，并对代码进行全量查看。
3.3 检查报告
面对不同的指标受众，检查报告内容的角度也是等同重要的！例如一般开发人员须要尽可能多的缺点详细信息；管理人员专一于问题概览，关注目前的产品是否能够公布，对于整体的问题散布；平安人员专一于代码里破绽等。
检查报告外面通常列出针对某个我的项目发现的问题信息。例如：总共发现了多少个问题。这些问题中，致命的有多少，重大的有多少，个别的有多少，提示性的有多少，以及问题最多的 TOP 查看规定，等等。点击相干的链接，能够进一步查看更为具体的问题信息。
针对检查报告外面的列出的缺点内容，通常状况下，开发人员须要逐条修复，而后再次提交审核。
对于局部查看后果，开发人员可能不采取修复动作，而是对其进行屏蔽。屏蔽的次要起因包含：1）检查报告中可能存在误报；2）局部代码不适宜批改；3）提示性的问题；4）开源代码；等等
• 误报：软件剖析技术面临的外围挑战之一是精确性与代码规模不可兼得。例如，为了在无限的工夫内返回查看后果，许多工具不进行门路敏感等深度的剖析。这将导致后果中蕴含一些漏报与误报。因而开发人员发现某条报告中列出的查看后果是误报时，能够对其进行屏蔽。
• 不适宜批改的代码：少数是为了防止执行效率的升高，对于不重大的问题，能够不做批改。
开发人员基于代码查看零碎提供的“申请屏蔽”入口，能够在零碎中记录下屏蔽信息，下次零碎就不再报出这个问题了，以缩小对开发人员的烦扰。对于开发人员提交的申请屏蔽信息，通常须要有专门的人员进行审核，以保障屏蔽的合理性。
点击关注，第一工夫理解华为云陈腐技术~