Misra 嵌入式软件标准
我需要使大量代码符合 MISRA 标准。
第一个问题：有人可以根据经验对嵌入式系统编写良好的代码进行估计吗？ 我知道“写得好”的定义不明确且模糊，因此我要求进行原始估计。
第二个问题：对于可定制（即允许抑制特定警告）并在自动构建环境（即命令行界面）中使用的工具有什么建议
任何其他可以帮助完成此任务的有用建议。
谢谢伊利亚。
I have a requirement to make a large amount of code MISRA compliant.
First question: Can somebody to give an estimation for passing well written code for embedded system based on experience. I understand that "well written" is poorly defined and vague so i ask for raw estimation.
Second question: Any recommendation for tool that can be customizable (i.e allowing suppress specific warnings) and used in automatic build environment (i.e command line interface)
Any other useful suggestions that can help with this task.
Thanks Ilya.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我还强烈推荐 PC-Lint。 如果您碰巧使用 Visual Studio 编译代码，我推荐使用 Riverblade 的插件“Visual Lint”。 如果无法在 Visual Studio 中编译代码，仍然可以从命令行运行 PC-Lint，效果良好。
某些嵌入式系统编译器提供 MISRA 合规性测试作为编译器警告。 我使用IAR编译器进行Arm7/Arm9开发。 它在编译器设置中提供了一个易于配置的 MISRA 合规性检查表。
很难想出一个经验法则来估计编写一些符合 MISRA 要求的良好代码所需的时间。 很大程度上取决于程序员现有的编码习惯以及他们最初遵循 MISRA 规则的程度。
粗略估计：
2 - 3 天即可熟练掌握 PC-Lint 的使用。
使现有代码符合 MISRA 的初步通过：首先花费 10% 到 25% 的时间编写代码。
保持代码符合 MISRA 标准：代码开发增加 5% 到 10%。 其中一半成本用于改变编码员的习惯，以遵循“MISRA 方式”做事。 另一半是代码测试和检查的额外成本，以确保 MISRA 合规性。
I also highly recommend PC-Lint. If you happen to be compiling your code with Visual Studio I recommend a plug-in 'Visual Lint' from Riverblade. If you cannot compile the code in Visual Studio, you can still run PC-Lint from the command line to good effect.
Some embedded system compilers provide MISRA compliance testing as compiler warnings. I use the IAR compiler for Arm7/Arm9 development. It provides an easy to configure MISRA compliance checklist right in the compiler setup.
It is difficult to come up with a rule of thumb for estimating the time it would take you to make some well written code MISRA compliant. A lot depends on the existing coding habits of the programmers and how closely they follow the MISRA rules in the first place.
Rough estimates:
2 - 3 days to become adept at PC-Lint usage.
Initial pass at making existing code MISRA compliant: 10 to 25 percent of the time spent writing the code in the first place.
Keeping code MISRA compliant: 5 to 10 percent added to code development. Half of this cost is changing the habits of your coders to follow the 'MISRA way' of doing things. The other half is the extra cost of code testing and inspection to ensure MISRA compliance.
我明白这是一个老问题，但为了任何其他考古学家（或搜索者）的利益，重要的是要记住 MISRA 提供了不应总是盲目遵循的指南。
我建议在编写新代码时牢记 MISRA； 因此，保持合规性会容易得多。
然而，这并不总是可能的 - 特别是在尝试对代码进行逆向工程以满足准则时。 在这种情况下，我建议您重点关注必需的规则，并将建议视为奖励...成本与收益也适用于此！
另外，请记住，存在偏差过程 - 最好保持干净且可维护的偏差代码，而不是设计一些合规但难以辨认的意大利面条。
I appreciate that this is an old question, but for the benefit of any other Archaeologists (or searchers), it is important to remember that MISRA provides guidelines that should not always be blindly followed.
I commend writing new code with MISRA in mind; therefore it will be a lot easier to stay compliant.
However, this is not always possible - and in particular, when trying to reverse engineer code to meet the guidelines. In this case I suggest that you focus on the Required rules, and treat the Advisories as a bonus... cost v benefit applies here too!
Also, bear in mind that there is a deviation process - it is better to keep clean and maintainable code with a deviation, than to contrive some compliant but illegible spaghetti.
我使用了一个名为 QAC 的商业工具。 该工具能够强制执行 MISRA
它有一个命令行界面，因此您可以对其进行设置可以从自动化构建环境中运行。 要应用的规则是可配置的，但希望有人花一些时间来设置它。 MISRA 的执行非常简单并且运作良好。 有人告诉我（这只是第三手资料），这是一些机构（例如 FDA）用来评估代码的工具之一。 与大多数静态分析工具一样，需要处理噪声（误报）。 上次我使用它时，它没有一个好的方法来标记/阻止误报再次发生（不更改它所抱怨的代码）。
我怀疑初级工程师最多需要一周（4-5 天）的时间来完成设置（假设他们决心让它按照您想要的方式工作）。
顺便说一句，其他商业静态分析工具也可能有 MISRA 强制执行。 据报道（根据他们的销售代表），Klocwork 确实如此。
I have used a commercial tool called QAC. The tool is able to enforce MISRA
It has a command-line interface, so you can set it up to run from a automated build environment. The rules to be applied are configurable, but expect to have someone spending some time setting it u. The MISRA enforcement is pretty straightforward and worked well enough. I was told (and this is just 3rd hand) that this is one of the tools some agencies (such as the FDA) use to evaluate code. Like most static analysis tools there is noise (false positives) to deal with. The last time I used it, it didn't have a good means to mark/stop a false positive from occurring again (without changing the code it was complaining about).
I suspect a junior engineer will take up to a week (4-5 days) to get it setup (assuming they are determined to get it working as you want).
On a side note, other commercial static analysis tools likely have MISRA enforcement as well. Reportedly (per their sales rep), Klocwork does.
我使用 PC Lint 对 C 和 C++ 代码进行静态分析。 它可以配置为显示哪些 MISRA 规则被违反，并且它有一个命令行界面。
I use PC Lint for static analysis of C and C++ code. It can be configured to show what MISRA rules have been violated, and it has a command line interface.
如果您遵循相当好的编程实践，那么使代码符合 Misra 规范并不是一件很麻烦的事。 如果您试图遵守的代码有一些奇怪而美妙的指针算术，您可能会发现某些指针规则有点棘手。
我赞同 Greg 对 PC Lint 的推荐，但开源 Splint 也值得一看，尽管在它们（以及编译器的警告系统）之间，我估计您仍然只能覆盖 80% 的 Misra 规则- 其余的可能需要手动进行代码审查。
Making code Misra compliant it not too much of a chore - if you follow fairly good programming practices. You might find some of the pointer rules slightly tricky, if the code you're trying to make comply has some weird and wonderful pointer arithmetic.
I'd second Greg's recommendation for PC Lint, but the open-source Splint is also worth looking at, although between them (and the compiler's warning system), I estimate you'll still only be able to cover 80% of the Misra rules - the rest will probably need to be code reviewed by hand.
我们在改造 Misra 规则时也遇到了类似的问题。 我们在一个大型项目中遇到了一些代码质量问题，并决定使用 MISRA 来提高代码质量。
我们使用支持 MISRA C 规则的 Green Hills 编译器。 还有独立的检查器可用。 根据你想要做什么，切换所有规则可能有点过头了。 我们一次打开一个规则，让人们有时间修复有限数量的类似问题，否则你会被大量的错误完全淹没。
由于我们的警告是由编译器生成的，而不是由独立工具生成的，因此您在开发时会看到错误，而不仅仅是在运行检查器时看到错误。 随着我们继续开发，我们的代码变得兼容，而不是一蹴而就。 这也可以防止旧习惯破坏新代码，导致您稍后必须再次修改代码。
有时很难使旧代码兼容，因为没有人确切知道代码是如何工作的。 我希望你有单元测试。
We had a similar problem of retrofitting Misra rules. We had some code quality issues on a large project and decided to use MISRA to improve the code quality.
We use the Green Hills compiler that has support for MISRA C rules. There is also stand alone checkers available. Depending on what you want to do it can be a bit over kill switching on all the rules. We switched one the rule on at a time to give people time to fix a limited number of similar problems else you get totally overwhelmed by the amount of errors.
Since our warnings was generated by the compiler and not by a standalone tool you see the errors as you develop and not only when you run the checker. As we continued developing we got our code compliant and not in one big bang. This also prevent old habits spoiling the new code causing you to having to rework the code again later.
Some times it is difficult to get old code compliant since nobody knows exactly how the code works. I hope you have unit tests.