背景

《方舟编译器C++语言编程规范》主体部分起源于《华为C++语言通用编码规范》，据悉又参考《Google C++ Style Guide》引入部分内容，其定义了方舟编译器编码规范的主体，但仍然存在一些问题：

误导性的描述

举例来说：

《方舟编译器C++语言编程规范》-> 0 前言 -> 约定

本规范适用通用C++标准, 如果没有特定的标准版本，适用所有的版本(C++03/11/14/17)。

方舟编译器当前采用的是clang的C++14版本进行编译，而规范C++03/11/14/17带有明显的误导性，C++17的新增特性是无法使用的，C++03的部分特性已废弃。

通用规范的局限性

《华为C++语言通用编码规范》面向整个华为公司而制定，《Google C++ Style Guide》面向其众多开源项目而制定，其皆为Single Rule Multi Projects的模式。不同的项目由于其历史性、外部项目依赖、开发角色习惯等等的不同，导致这类通用规范在很多细节上需要保证一定的灰度，不能眉毛胡子一把抓。

而专属编码规范并没有这样的问题，如若直接引用通用编码规范的约束，那倒是宣扬一种不伦不类的“自由”，并没意识到不作为会引入更多的麻烦。

举例来说：

《方舟编译器C++语言编程规范》-> 4 注释 -> 注释风格

在 C++ 代码中，使用 /* */和//都是可以的。 按注释的目的和位置，注释可分为不同的类型，如文件头注释、函数头注释、代码注释等等； 同一类型的注释应该保持统一的风格，建议： 1）文件头注释使用/* */。 2）同一文件内函数头注释、代码注释要使用相同的注释符，不可混用。

注意：本文示例代码中，大量使用 ‘//’ 后置注释只是为了更精确的描述问题，并不代表这种注释风格更好。

在使用/* */还是//的问题上，其仅对文件头注释进行了强制约束，对于函数注释、类注释、块注释等，仅在建议中做了一个笼统的描述，这便导致了**.h**文件与**.cpp**文件注释风格不一致，乃至当文件过大，或存在代码转移时，同一文件注释不一致的情况。

规范中的例外

规则和建议都有例外，但《方舟编译器C++语言编程规范》中并未对例外场景进行补充，这便导致了一刀切的代码检视，以及许多反复的例外场景的咨询和讨论。同时由于编译器并非常驻服务，且面向底层设计，所以其中必然存在符合其特色的例外场景，以及针对这类开发群体的例外场景。

增强规范

《方舟编译器C++语言编程规范：增强规范》便是在《方舟编译器C++语言编程规范》的基础上，结合开源整改、SESC整改、代码检视等经验，统一方舟中端团队的C++开发。我们期望此规范可以达成以下几个目标：

  1. 规范中的例外或模糊的边界有明确的定论，以及其分析和示例。
  2. 以往的经验总结不再是分散的记录或文档，而在此增强规范中统一有理有据的承载。
  3. 大多数编码规范不靠死记硬背，而应在理解的基础上达到福至心灵、心至慧生。

此增强规范将分为三部分：

  1. 格式规范：此类规范主要影响代码可读性，而对代码功能或性能无影响。包括：命名、换行、空格、注释等
  2. 语言规范：此类规范针对C/C++提供的语言特性，主要对代码的功能和性能有影响。如auto关键字、基于范围的for等
  3. 设计规范：此类规范主要面向代码组织和关系设计，既可能为了可读性，亦可能为了可扩展性，甚至可能会牺牲微量性能。如在某些场景下使用工厂模式替代switch...case...