文章总结： 本文档详细介绍了JSFAVC++编码标准中关于命名空间、模板和函数的核心规则。主要内容包括：非局部名称应置于命名空间内且嵌套不超过两层；模板需从自身和实例化两方面审查并覆盖测试；函数声明应在文件作用域，禁止可变参数和递归，限制参数不超过7个，并强调单一出口和错误返回值检查。这些规则旨在提升代码质量、安全性和可维护性。 综合评分： 75 文章分类： 安全开发
【第三部分】写出军规级代码：JSF AV C++编码标准
原创
crackme.net crackme.net
crackme安全实验室
2026年7月8日 12:49 河南
在小说阅读器读本章
去阅读
命名空间
AV Rule 98：非局部名称应置于命名空间中
规定（Should）：除 main() 函数外，所有非局部名称都应放置在某个命名空间内。
理由：避免在由多个模块组成的大型程序中出现名称冲突。
例外情况：main() 函数不受此规则约束。
AV Rule 99：命名空间嵌套深度限制
规定（Will）：命名空间的嵌套层级不得超过两层。
理由：保持代码的简洁性与清晰性；过深的命名空间嵌套会增加理解和正确使用的难度。
AV Rule 100：命名空间元素的选择方式
规定（Should）：引入命名空间元素时应遵循以下策略：当仅需少量（约五个以内）名称时，使用 using 声明或显式限定；当需要大量名称时，方可使用 using 指令。
理由：避免在仅需少数元素时将整个命名空间的所有内容都引入当前作用域，以减少不必要的名称污染。
模板
尽管模板技术已被证明非常强大，但在何时使用模板而非继承可能并不明确。Stroustrup 在其著作第 13.8 节中提供了以下指南：
- 1. 当运行时效率至关重要时，优先选择模板而非派生类。
- 2. 如果在不重新编译的情况下添加新变体很重要，则优先选择派生类而非模板。
- 3. 当无法定义公共基类时，优先选择模板而非派生类。
- 4. 当内置类型以及具有兼容性约束的结构体很重要时，优先选择模板而非派生类。
AV Rule 101：模板审查要求
规定（Shall）：模板必须从以下两个方面进行审查：
- 1. 孤立地审查模板本身，考虑对其参数所做的假设或要求；
- 2. 审查由实际参数实例化的所有函数。
理由：由于模板可能生成大量实例化版本，审查时必须涵盖所有实际实例化情况以及对实例化参数的假设和要求。编译器应配置为生成实际模板实例化列表以辅助审查。
AV Rule 102：模板测试覆盖要求
规定（Shall）：必须创建模板测试用例以覆盖所有实际的模板实例化。
理由：由于模板可能生成大量实例化版本，测试必须确保覆盖所有实际发生的实例化。
AV Rule 103：模板参数约束检查
规定（Should）：应对模板参数应用约束检查。
理由：在代码中显式捕获参数约束，并产生易于理解的错误信息。
AV Rule 104：模板特化声明顺序
规定（Shall）：模板特化必须在使用之前进行声明。
理由：这是C++语言规则要求，特化必须在其所特化的类型每次使用时都处于作用域内，否则将导致编译错误或使用了错误的通用模板版本。
template<class T> class List {…};
List<int32*> li;
template<class T> class List<T*> {…}; // 特化声明顺序错误
AV Rule 105：最小化模板对实例化上下文的依赖
规定（Should）：应最小化模板定义对其实例化上下文的依赖。
理由：模板可能在多种不同参数类型的上下文中被实例化，任何非局部依赖都会增加最终出现错误或不兼容的可能性。
AV Rule 106：指针类型的模板特化
规定（Should）：在适当的情况下应为指针类型提供模板特化。
理由：指针类型通常需要特殊的语义处理或能提供特殊的优化机会，通用模板实现可能无法满足这些需求。
函数
函数声明、定义与参数
AV Rule 107：函数声明作用域
规定（Shall）：函数必须始终在文件作用域进行声明。
理由：在块作用域中声明函数容易引起混淆。
AV Rule 108：禁止使用可变参数函数
规定（Shall）：不得使用具有可变数量参数的函数。
理由：可变参数特性难以以类型安全的方式使用，编译器通常不会对额外参数应用常规的语言检查规则，容易引发运行时错误。
备注：在某些情况下，可使用默认参数和函数重载作为可变参数的替代方案。
AV Rule 109：类定义中函数定义的放置
规定（Should）：除非函数明确意图被内联，否则不应将函数定义放置在类定义中。
理由：在类定义中包含成员函数实现会使类定义变得冗长且难以阅读；但将实现放在类定义中会指示编译器尝试内联该方法，对于旨在内联的短函数，这样做可以节省时间和空间。
例外情况：明确意图被内联的短函数可以出现在类定义中。
AV Rule 110：函数参数数量限制
规定（Will）：不得使用参数超过7个的函数。
理由：过长的参数列表会使函数难以阅读、使用和维护；参数过多可能表明未充分利用对象和抽象机制。
例外情况：某些构造函数可能需要超过7个参数，但在这种情况下仍应审视是否存在抽象使用不足的问题。
AV Rule 111：禁止返回非静态局部对象的指针或引用
规定（Shall）：函数不得返回指向非静态局部对象的指针或引用。
理由：函数返回后，局部对象将被销毁，返回的指针或引用将悬空，导致未定义行为。
AV Rule 112：函数返回值与资源所有权
规定（Should）：函数返回值不应模糊资源的所有权归属。
理由：返回值若不能清晰表达资源所有权，可能导致资源泄漏或双重释放等严重问题。
返回值
AV Rule 113：函数单一出口点
规定（Will）：函数应当具有单一的退出点。
理由：多个退出点往往会导致函数难以理解和分析。
例外情况：如果强制单一出口会掩盖或显著复杂化函数的控制逻辑（例如需要引入额外的变量），则不要求单一出口；但需注意在所有退出点都必须进行常规的资源清理。
AV Rule 114：返回值函数的退出方式
规定（Shall）：所有返回值函数的退出点必须通过 return 语句实现。
理由：从返回值函数的末尾隐式流出（falling off the end）会导致未定义行为。
AV Rule 115：错误返回值的检查
规定（Will）：如果函数返回错误信息，则该错误信息必须被测试/检查。
理由：忽略返回值可能导致应用程序在错误地假设运行上下文（或操作对象）有效的情况下继续处理，从而引发严重后果。
函数传参方法：值 指针 引用
AV Rule 116：小型具体类型参数的值传递
规定（Should）：对于小型、具体类型的参数（大小为两到三个字），如果不需要将对形参的修改反映到调用函数中，则应通过值传递。
理由：对于小型具体类型对象，值传递是最简单且最安全的方法；但需注意非具体对象必须通过指针或引用传递以实现多态行为。
AV Rule 117：不可能为 NULL 时的引用传递
规定（Should）：当参数不可能为 NULL 值时，应通过引用传递参数。
- • 若函数不应修改对象值，应作为
const T&传递 - • 若函数可能修改对象值，应作为
T&传递
理由：由于引用不能为 NULL，使用引用可以消除代码中对 NULL 值的检查，并且引用提供了比指针更便捷的表示法。
AV Rule 118：可能为 NULL 时的指针传递
规定（Should）：当参数可能为 NULL 值时，应通过指针传递参数。
- • 若函数不应修改对象值，应作为
const T*传递 - • 若函数可能修改对象值，应作为
T*传递
理由：引用不能为 NULL，因此当需要表达“可选”或“空”语义时，必须使用指针。
AV Rule 119：禁止递归
规定（Shall）：函数不得直接或间接地调用自身（即不允许使用递归）。
理由：由于栈空间并非无限，递归调用可能导致栈溢出。
例外情况：在以下情况下允许使用递归：
- 1. 开发 SEAL 3 或通用软件时；
- 2. 能够证明存在充足的资源以支持可能达到的最大递归深度。
AV Rule 120：重载一致性
规定（Should）：重载的操作或方法应构成一族：使用相同的语义、共享相同的名称、具有相同的目的，并且仅通过形式参数进行区分。
理由：不一致地使用重载会导致严重的混淆。
内联函数
AV Rule 121：内联函数的候选条件
规定（Should）：仅包含 1 条或 2 条语句的函数才应被视为内联函数的候选对象。
备注：编译器并不强制将函数实际内联，inline 关键字仅是对编译器的请求，编译器可自由忽略该请求并执行真实函数调用；不同编译器的决策标准各异，限制函数体大小可提高内联成功的可能性。
AV Rule 122：简单访问器和修改器函数的内联
规定（Should）：简单的访问器（accessor）和修改器（mutator）函数应被声明为内联函数。
理由：对短小、简单的函数进行内联可以同时节省时间和空间开销。
AV Rule 123：最小化访问器和修改器函数的数量
规定（Should）：应尽量减少访问器和修改器函数的数量。
理由：大量的访问器和修改器可能表明该类仅用于聚合数据集合，而非体现具有明确定义状态或不变量的抽象；在这种情况下，使用包含公共数据的结构体可能是更好的替代方案。
AV Rule 124：简单转发函数的内联
规定（Should）：简单的转发函数应被声明为内联函数。
理由：对短小、简单的函数进行内联可以同时节省时间和空间开销。
AV Rule 125：避免不必要的临时对象
规定（Should）：应避免创建不必要的临时对象。
理由：创建和销毁体积较大或构造复杂的临时对象会导致显著的性能损失，因此应当避免。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：crackme安全实验室 crackme.net crackme.net《【第三部分】写出军规级代码：JSF AV C++编码标准》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论