C++编码规范：JSF-AV（未完待续）
联合打击战斗机计划（英语：Joint Strike Fighter Program，简称JSF）是一个由美国和其盟国发起的新一代战斗机发展和采购项目。该项目旨在取代大量已老化的战斗机、战斗轰炸机和攻击机。该项目计划在未来取代各种西方主力战机，包括F-16、A-10、F/A-18、AV-8B和海鹞式战机。波音的X-32方案和洛克希德.马丁（Lockheed Martin，下文简称“洛马”）公司的X-35方案进入了最后的角逐。
经过各阶段试验后，X-35于2001年10月26日击败X-32获选，并授予编号为F-35。之后，联合打击战斗机计划正式进入了系统研制与验证（System Development and Demonstration，SDD）阶段。该阶段为期126个月，总费用高达200亿美元。
在系统研制与验证阶段，洛马公司专门编写了JSF项目的C++编程规范以约束相关开发人员和供货商提供的软件代码。该编程规范全称为《联合打击战斗机项目系统研制与验证阶段航空器C++编程规范》。该编程规范在2005年一年内完成编写，期间共经历2次修改，最新版本为“Rev C”。
该编程规范旨在为C++程序员提供指导，使其编写代码都具有良好的编程风格并经过相应的验证，从而保证代码安全性、可靠性、可测试性和可维护性。
洛马公司要求相关航空器系统代码强制遵循该规范，并推荐其它非航空器系统代码参照执行。
该编程规范在编写时借鉴了MISRA C 安全编程规范的相关内容，并在其之上增加了针对继承、模板和命名空间等C++特性的编程规范。
该标准希望通过相关约束来保证代码具有以下几个特性：
可靠性：代码应该以可预测的方式执行，并满足所有要求。
可移植性：源代码不应包含依赖编译器或链接器的内容
可维护性：代码应风格一致、设计简单且易于调试。
可测试性：代码应在规模大小、复杂性和静态路径数量这三个维度尽量保持较低数值，以此减低测试工作的难度。
可复用性：鼓励使用可复用组件。
可扩展性：期望在软件系统全周期中可以不断发展，并为此提供相应支持或基础。
可读性：源代码应该以易于阅读、理解和使用的方式编写
同时，该编程规范针对代码的耦合性与内聚性提出了如下要求：
- 将与硬件和外部软件的交互限制在少数函数内；
- 尽量减少对全局数据的使用；
- 尽量不暴露实施细节。
该编程规范有“shall”“will”和“should”三个遵守级别，其各自代表内容如下：
- should属于较为强烈的建议要求
- will属于强制性要求，但是这类要求不要求验证，因此这类要求仅限于非安全攸关(non-safety-critical)的要求，例如命名约定等；
- shall也属于强制性要求，但是这类要求必须由工具或人工进行确认。
与其它编程规范不同的是，该编程规范明确说了如果在编程过程中确实需要违反相关规则所需的手续。这一点是与其它编程规范完全不同的，它体现了该规范作为洛马内部编程要求的实操性。建议有内部编程规范的公司也借鉴该部分。该部分具体内容包括：
- 当违反“should”规则时，需要有软件开发负责人（software engineering lead）的批准；
- 当违反“will”和“shall”规则时，需要有软件开发负责人和产品经理的批准
- 所有对“shall”级规则的违背都应有相应记录文档。
在内容上，每条规范以“AV”为标识符，例如 "AV Rule 1"指第一编程规范。每个编程规范分为描述、原因解释、示例和备注四个部分。
描述用于说明要求内容，该规范的描述都比较简略，有时还会省略为“参见其它规范或书籍的XXX条”。同时，该部分有时还包含大量其它航空标准的内容，例如“只有符合DO-178 A级或SEAL 1级认证的C/C++ 库函数可以在安全攸关（SEAL 1）的代码中使用”。其中DO-178是指“《机载软件适航标准》Software Considerations in Airborne Systems and Equipment Certification”，而“SEAL 1”则是在《JSF系统安全项目计划》JSF System Safety Program Plan中定义。由此可以看到，该编程规范与其它航空或JSF项目文档紧密相关，也从一个侧面反映了洛马及欧美航空领域规范体系的建设水平。
示例（Examples）部分为遵守或违反相关规则的代码。该部分内容较少，且仅有少量规则有对应示例，不过在该文档的附录中有大量针对具体规则的示例。
原因解释（Rationale）用于阐述设定该规则的原因，通过该内容，编程人员可以“知其所以然”。同时，该部分内容是其它很多编程规范所缺失的
备注（Note）涉及范围比较多，包括遵守要求、编译选项等。
代码量和复杂度
任何一个方法或函数的总行数不应超过200行。
过长的函数会导致逻辑复杂且不利于测试。
There shall not be any self-modifying code。
所有函数的复杂度不能高于20。
C++编码标准
术语
抽象类（abstract base class）是不能创建实体的类，它只能作为基类由其它类来继承，抽象类至少包含一个纯虚函数。
抽象数据类型（abstract data type）
4.9 风格
代码每行的字符数小于或等于120个。
4.9.1 命名标识符
Rule 45
标识符的每个单词中间用“_”符号间隔。
Rationale 可读性
Rule 47
标识符不要以“_”开头。
4.9.1.1 命名类、结构体、枚举类型
类、结构体、枚举、命名空间、以typedef定义的类型等命名以大写字母开头，其余字母小写。
Example
// Only first letter is capitalized;
class Diagonal_matrix { … };
// RGB is an acronym so all letters are un upper case
enum RGB_colors {red, green, blue}; 4.9.1.2 命名函数、变量和参数
函数、变量、参数的命名都要用小写字母。
Example
class Example_class_name
{
public:
uint16 example_function_name (void);
private:
uint16 example_variable_name;
};4.9.1.3 命名常量和枚举
标识符都要使用小写字母。
注：在此建议按照Google编码规范，命名时以 “k” 开头, 大小写混合。使用Google方法便于将常量、枚举与其它类型数据区分。
// 常量
const int kDaysInAWeek = 7;
// 枚举。枚举命名不要参考
enum UrlTableErrors {
kOK = 0,
kErrorOutOfMemory,
kErrorMalformedInput,
};
enum AlternateUrlTableErrors {
OK = 0,
OUT_OF_MEMORY = 1,
MALFORMED_INPUT = 2,
};4.9.2 命名文件
Rule 53
头文件（Header files）的扩展名应为“.h”。
Rule 53.1
下列字符不应出现在头文件中：'， \，/*，//，"。
Example
// Bad: “/*” prohibited
#include
// Bad: “’” prohibited
#include
// Bad: “\” prohibited
#include
// Good: relative path used
#include Rule 54
源文件（Implementation files）的扩展名应为“.cpp”。
4.9.3 类（Class）
Rule 57
类的public、protected和private部分按照以上顺序在头文件、源文件中声明和定义。
4.9.4 函数（Function）
当声明、定义的函数有多于2个参数时，第一个参数与函数名同行，其余参数各占一行，括号“)”与最后一个参数同行。