在日常维护嵌入式工程的时候，经常会碰到不知道怎么筛选TASKING编译警告，还有怎么把这些警告和代码规范对应起来的难题，我们真正需要做的，是把这些警告按照风险大小、不同模块、规则来源还有处理状态给分类分清楚。

　　一、TASKING编译警告怎么筛选

　　在筛选TASKING编译警告的时候，不建议大家只盯着Problems那个窗口里面的总数字看，因为数字多只能代表提示的信息很多，它并不能告诉我们哪些是必须马上改的，哪些是可以往后挪挪的，还有哪些是因为配置没弄好导致的重复报出来的警告。

　　1、先按警告编号筛选

　　TASKING这个软件给出的诊断信息一般都有自己的类型和编号，像是warning、error、information这些不同类别，我们在Problems窗口里能看到这些信息，拿鼠标右键点一下还能看到更详细的诊断，如果在命令行下面，大家也可以用--diag这个命令去查看某个指定编号或者全部的诊断说明。

　　2、再按模块和文件筛选

　　这个地方需要我们结合着工程的目录结构去观察，如果说某个文件夹底下突然冒出来一堆警告，那可能不是因为代码突然变烂了，有可能是因为包含的include路径、宏定义、芯片的型号，或者是编译的配置被谁给改动了，就像我们以前迁移工程的时候，某个芯片的宏漏了没定义，编译器跑进了错误的条件编译分支里面，警告的数字就会一下子变得特别多。

　　3、区分新增警告和历史警告

　　做老项目的时候，最怕的就是一下子把所有的检查开关都打开，然后非逼着大家当天就把警告全部清零，这样很容易把真正的代码风险和以前留下来的老问题给混在一块了，比较好一点的办法是先做一份警告基线，把现在已经有的警告先固定死，后面我们只盯着新冒出来的警告就行。

　　二、TASKING编译警告和代码规范怎么对应

　　编译警告和代码规范其实并不是同一回事，编译器的警告一般更偏向于语法对不对、类型合不合规、目标平台还有编译时候的动作；而代码规范管得更宽，它还会管到命名好不好听、代码结构、复杂度、可读性、安全规则、注释怎么写还有项目的各种约定，这两个东西得对上，但是不能简单地画等号。

　　1、把警告编号对应到规范条款

　　我们的项目可以自己做一张表格，把警告编号和规范的条款给对应起来，比如说看到类型转换的警告，就可以让它对应到“禁止隐式窄化转换”或者是MISRA的某条规则；看到没用到的变量，就可以对应到“禁止无效代码”；发现函数声明不一致，就可以对应到“接口声明必须统一”。

　　TASKING内部自己就支持MISRA C的检查，这个相关的设置一般是在【C/C++Compiler】→【MISRA C】里面去配的，我们可以自己选要检查哪几条MISRA C规则，里面有一部分mandatory、required、advisory的规则，也都可以被我们调成用warning的方式打印出来。

　　2、按严重程度制定处理策略

　　在写代码规范的时候，不能光写一句“要把所有的警告都消掉”，这种话写得太宽泛了，大家执行的时候容易变形，我建议把警告分成这么几类：必须马上改掉的、提交代码之前必须改掉的、版本发布出来之前必须改掉的、还有写明原因之后允许留着的；

　　3、把警告处理纳入门禁

　　如果你们团队平时有用持续集成或者版本门禁的话，可以设置成“只要新长了warning就不允许合并代码”，而不是硬逼着那些老项目一次性做到零警告，这样干更符合实际项目的开发节奏，大家也更容易接受并推进下去。

三、TASKING编译警告怎么处理

　　等我们把警告都筛出来之后，下一步可不是马上把它们关掉，而是得琢磨琢磨它到底属于代码写错了、规范没对上、配置没弄好，还是只是工具的一个小提示，面对不一样类型的警告，我们的处理办法也得换一换。

　　1、真实代码问题要修改代码

　　在解决这类警告的时候，我们应该优先去改代码本身的逻辑，比如说把函数的原型给补齐、把类型转换写得更明确一点、给变量赋个初值、检查一下返回值、顺便看看数组的边界对不对，千万别为了让编译顺利通过，就在代码里瞎加一堆强制类型转换，这么干只是把警告藏起来了，并不代表背后的风险真的被解决了。

　　2、配置引起的警告要回查编译选项

　　如果这些警告是在你刚导入了配置、升级了TASKING的版本、或者在Debug和Release模式之间切换之后突然变多的，那就要先去检查编译选项了，我们可以重点看看【Project】→【Properties】→【C/C++Build】→【Settings】里面的Diagnostics、Preprocessor、Include Paths、Language、Optimization、MISRA C这些设置页面。

　　3、确认无风险的警告再抑制

　　TASKING是支持在【C/C++Compiler】→【Diagnostics】里面通过输入编号来把警告关掉的，我们可以输好几个编号或者是一个编号的范围，要是把suppress all warnings给勾上了的话，那所有的warning就都被屏蔽了。

　　总结

　　要想搞清楚TASKING编译警告怎么筛选，还有TASKING编译警告和代码规范怎么对应，核心的办法就是先把警告按照编号、属于哪个模块、是新是旧以及风险有多大给分类理顺，在筛选的时候，大家能用Problems窗口、详细诊断信息还有--diag命令去查原因；在处理的时候，千万别直接把所有的warning全关了，而是要分清楚到底是代码写错了、配置没对上、第三方库的问题还是以前留下的老毛病，在和代码规范做对应的时候，我们可以把TASKING的警告编号、MISRA规则、团队自己的规范条款以及处理的办法，全都塞到同一张表格里去管，这样处理警告就不单单是去“刷数字”了，而是能真正帮我们把好代码质量和项目交付这两道关。