MISRAC:2004学习记录（2019/11/08）

MISRA-C适用范围

- 语言：C/C++

- 不提供主观性约束和建议：代码编码规范、静态检查工具

- 应用于汽车工业嵌入式领域

- "free-standing"

- 阅读此标准需先具备ISO-C语言

- C++，C++并非C的super-set，C++代码检查完全遵守ISO C标准且不允许C++注释出现在ISO C中

- 对于自动生成代码要谨慎选择有验证功能的自动生成工具，并与人工代码遵守相同规则

MISRC-C的使用

C源码正式培训内容包括：

- C在嵌入式场景下的使用

- C在高一致性和安全性场景下的使用

- 静态检查工具的支持

代码风格

需要明确定义内部代码风格，该风格与源码准确性无关，只是作为公司内部的统一源码风格。其中大部分为建议，只有少部分是强制的。

- 代码布局和缩进

- "{ }"布局和代码块结构

- 语句的复杂度

- 命名规范

- 注释内容的使用

- 公司名称、版权及其他标准的头文件信息

工具的选择与验证

- 符合ISO C规范的编译器的输出应该与编译器说明文档一致。

- 静态检查工具应该能够强制检测尽可能多的在本文档中描述的规则，并能够全局检测整个工程而非单个文件。

- 通常，编译器和静态检查工具被认为是可信赖的。

- 静态检查工具自身提供版本控制：记录代码检查中出现的问题和修改记录：

1. 用户上报错误的记录

2. 已知问题要及时通知到用户

3. 在下一个release中及时修复这些问题

开发者可以采用以下方法去验证检测工具是否值得我们信赖：

- 执行文档中描述的测试测试

- 直观参与到检测工具的开发中

- 定期回顾检测工具的性能

需要提醒是链接器、加载器、编译器以及静态检查工具的版本需要保持兼容或一致。

源码复杂度指标

复杂度指标用于防止由于代码隐晦和不可测试性带来的超越已建立的检测规则的情况。大部分静态检测工具都具有生成指标数据的能力。

测试覆盖度

代码功能的预期应该在设计和编写之处就应该被考虑周全，测试用例能够覆盖所有代码声明的功能。"Design For Test"的理念应该深入到结构、电气和电子工程等领域。所有与该领域相关的测试用例都应该在代码设计之初就被考虑到如何进行测试。

模块化（Use of a subset）可以实现高内聚和松耦合，使代码的集成和测试更加容易。

以下内容可作为评估代码功能覆盖度的指标：

- 代码大小

- 网络复杂度

- 静态路径数

采用分组

- 生成用于声明各个规则如何加强的柔度矩阵

- 生成偏差程序

- 同质量管理团队一同规范化工作实践

柔度矩阵，通过多种静态检查工具确定所有规则均没有被破坏，必要时还要求人工参与

表1 柔度矩阵

开发者有额外的本地限制，这些同样要被添加到柔度矩阵中进行判别。当有明确的限制被忽略掉时，必须要有充分的理由去说明。这些判别需要有专业的C语言专家同经理级别的管理者一同参加评审。

偏差程序

针对一些权威认证的偏差（不在这些规则中的，而非程序员自身随意决定是否跳过的规则）需要经由每个权威专家去sign-off确认。通常这些偏差的确认流程由质量管理系统来负责。

项目偏差：

- 偏差的细节描述

- 这些偏差引起的上下文环境

- 偏差造成的潜在后果

- 安全性保证的展示

在开发后期产生的偏差，软件开发者需要提交一份“Specific Deviation Request”：

- 偏差的细节描述

- 偏差造成的潜在后果

- 对偏差的评判

- 安全性保证的展示

质量系统的形式化

将上述的静态检测工具、偏差处理文档化。以供内、外部质量系统的审计保持高度的一致性。

遵守声明

该遵守（MISRA-C）可以仅限于产品而并非组织。

持续改进

通过对各种指标的不断的提高软件的开发流程。