MISRA和AUTOSAR C++14会冲突吗MISRA规则与AUTOSAR规则重叠项该怎么处理，在C++汽车软件项目里头，这类问题一不留神就会冒出来。这两套规则其实全都是在盯着代码的安全程度、可维护程度和可移植程度使劲，它们之间倒不是那种死对头的关系，AUTOSAR C++14 Guidelines本来就是面向C++14的，而且跟MISRA C++:2008之间有一层很清楚的承接关系；后来推出来的MISRA C++:2023呢，又反过来把AUTOSAR C++14里头的不少经验给吸了进去，拿它来对付C++17相关的关键系统开发。所以多数时候，它们看着像是互相拌腿，实际上更可能是同一处风险被两套尺子各量了一回。
一、MISRA和AUTOSAR C++14会冲突吗
碰到的情况里面，两套规则直接顶牛的概率其实不高，更多时候只是规则的覆盖面、松紧的拿捏，还有编出来的号头不太一样。同一小段代码被两边一块儿揪住，猛一看就跟冲撞了似的，可掰开瞧，多半也就是重叠检查闹出来的动静。
1、同类问题可能顶着不一样的规则编号
像类型转换、指针的弄法、异常处理、表达式里夹带的副作用、资源的管理这些地方，两套规则是都有本事盖住的，就打个比方，一处不声不响的类型转换，MISRA这边说不定会甩出一条告警，AUTOSAR那头呢，也完全可能再兜上一条，可它们俩枪口指的其实是同一个代码风险，碰见这种事，先不用急着去拍板谁对谁错，不如先沉下来看它们俩的规矩本意是不是凑在一处的。
2、AUTOSAR C++14可能更细
AUTOSAR C++14对现代C++里头那些特性的限制，本来就是要多上不少的，比方说C++11和C++14当中新冒出来的一部分语言用法、资源是怎么个管法、还有面向对象那一套设计的路数等等，要是项目这头光照着MISRA C++:2008的标准去把代码捋过了一遍，放到AUTOSAR底下照样还是哗哗报错，这其实一点也不奇怪，倒不是两套规矩在里头互相打擂台，而是AUTOSAR把C++14场景底下的许多细节补得更密实了。
3、真正互相矛盾的情况较少
真能算得上互咬的景况，是一套规矩非要你照着这个模子来，可另一套规矩又明明白白不许你这么写，而在实实在在的项目里头，更多碰见的不过是一条规则把手松了松，另一条规则又使劲朝紧里勒了勒，碰到这一类的事情，一般也就是照着项目自己挑定的主规则集先去走，回头再给那些不一样的地方补上几笔说法就算过得去了。
二、MISRA规则与AUTOSAR规则重叠项该怎么处理
规则叠在一块儿的那些条目，既不能图省事一把头给砍掉，也不能翻来覆去地重复折腾上好几遍，比较讲得过去的招数是把它们全给揉到同一个套子里面，用项目自己定下的那套管法去一并对付。
1、先做规则映射
对照【MISRA规则编号】、【AUTOSAR规则编号】和【工具告警编号】，整理同类规则之间的对应关系。
这种映射的表倒不用一上来就码得多么精细，先把那些三天两头就撞上的重叠项给拢一拢就中用，就比方说类型转换那一摊、初始化那一摊、控制流那一摊、指针那一摊、宏那一摊，还有异常处理那一摊，这样等同一个代码位置同时被好几条告警叮住的时候，才好去断它到底是一个根子上引出来的毛病，还是真就犯了不一样的好几条规矩。
2、确定项目主基线
项目这边是可以直接把AUTOSAR C++14抱过来当那套主规则集的，然后再在一旁头标清楚它跟MISRA之间的那些重叠瓜葛；倒过来呢，也完全可以拿MISRA去打底子，只把AUTOSAR不同的那一部分当个补丁往上打，这里头的关节就在于嘴巴得咬齐了，要是项目一会照着MISRA去判，一转身又拿AUTOSAR去量，那头搞开发的人跟做审核的人，两边脑子可就全要搅成浆糊了。
3、重叠告警合并关闭
对照【静态分析报告】和【问题关闭记录】，把同一代码位置、同一根因、同一修改动作的告警合并处理。
就比如说，有一处类型转换它一下引来了两套规矩的告警，而不管是往哪头靠，动手去改的路子都是把那不声不响的转换给掰成明明白白的类型处理，那就可以权且当一个问题来给它收了口，只是在留下的记档里头把两条规矩的编号都保下来，这样一来既不会漏掉哪一条规矩，也犯不着把同一桩事活活撕成两瓣活儿派出去。
三、怎样避免两套规则越用越乱
当项目把MISRA和AUTOSAR C++14同时拉进来用的时候，最怕的就是工具的设配、规矩的清单，还有偏离开来的记档，全都各管各的不住在一个屋里，前头要是没先把口径给对拢了，后面攒下来的报告就只会一摞一摞地往上堆，越来越叫人招架不住。
1、工具规则集要固定
到底是开动哪几套规矩、哪些个规矩给关掉了、又有哪些规矩是不能全靠工具得靠人一双肉眼去审的，这些在项目才起头的时候就全要给敲死在那里，可不敢把工具出厂时候默认的那一包设配，二话不说就直接抱过来当做项目自己定下来的设配，因为不一样的工具，它对规矩的映射、告警能不能捏成一个、还有那些没法靠机器自个儿断定下来的规矩，处置它们的道道是各不一样的。
2、偏离说明要覆盖两套规则意图
要是叠在一起的那些项里头有哪一条非走偏离不可，那说明偏离由头的时候就不能只掰开其中一套就拉倒，打个比方，那些扒着硬件底层寄存器的驱动代码，偏就绕不开要用特殊的指针弄法，那就得把这一段代码为什么真不能改、藏在背后的风险是怎样勒住的、测试和评审的凭据又够不够这些，全给摆在明面上，要是光去跟MISRA那头把话圆上了，AUTOSAR这头还晾着没人理，报告里头照样是会豁着一道口子的。
3、规则升级时重新核对映射
假使项目哪天从AUTOSAR C++14或者MISRA C++:2008往上挪到了MISRA C++:2023，那前面辛辛苦苦攒下来的那套映射关系是不能原封不动就硬往新版本上套的，规矩的编号、它罩住的面，还有工具那头在底下的实现，全都有走样的可能，做迁移的时候，顶好是把规则的映射、偏离的记档，还有历史上关掉的那些项，全都翻出来重新对上一遍，免得拿着老早的结断去接着往下吃。
总结
MISRA和AUTOSAR C++14会冲突吗MISRA规则与AUTOSAR规则重叠项该怎么处理，说到底，答案一般不是硬要人在里头挑一个扔掉另一个，这两套规矩在大多数时候是接承的、是打补丁往下补细的、是互相盖来盖去的那么一种光景，真正闹到彼此顶牛的份上并不多见，在项目这头更要紧的事情，是把规则映射的底子给码实在了，把那个主打的基线给敲稳了，把叠在一处的告警给捏到一块儿去收拾，再让偏离记档能一肩把两头的规矩本意都扛起来，这样捋过一遍之后，规矩的查对就会变得清爽不少，后头再有人去维护的时候也不会一脚踩进去就摸不着北。
