大量のコードを MISRA に準拠させる必要があります。最初の質問:経験に基づいて、組み込みシステム用に適切に記述されたコードを渡すための見積もり
を
誰かに与えることができますか? 「よく書かれた」とは定義が不十分で曖昧であることを理解しているので、生の見積もりを求めます。
2 番目の質問: カスタマイズ可能 (つまり、特定の警告を抑制できる) で、自動ビルド環境 (つまり、コマンド ライン インターフェイス) で使用できるツールに関する推奨事項
。このタスクに役立つその他の有用な提案。
ありがとうイリヤ。
8851 次
6 に答える
12
PC-Lintも強くお勧めします。コードを Visual Studio でコンパイルする場合は、Riverblade の「Visual Lint」プラグインをお勧めします。Visual Studio でコードをコンパイルできない場合でも、コマンド ラインから PC-Lint を実行して効果を得ることができます。
一部の組み込みシステム コンパイラは、コンパイラの警告として MISRA 準拠テストを提供します。Arm7/Arm9 の開発には IAR コンパイラを使用しています。コンパイラーのセットアップで MISRA 準拠チェックリストを簡単に構成できます。
適切に記述されたコードを MISRA に準拠させるのにかかる時間を見積もる経験則を考え出すのは困難です。多くは、プログラマーの既存のコーディング習慣と、そもそも MISRA ルールにどれだけ厳密に従っているかに依存します。
概算:
PC-Lint の使用に慣れるまでに 2 ～ 3 日。
既存のコードを MISRA に準拠させるための最初のパス: 最初にコードを書くのに費やされた時間の 10 ～ 25%。
コードの MISRA 準拠の維持: コード開発に 5 ～ 10% が追加されます。このコストの半分は、「MISRA 方式」に従うようにコーダーの習慣を変えることです。残りの半分は、MISRA 準拠を保証するためのコードのテストと検査の追加コストです。
于 2008-09-15T15:11:25.610 に答える
8
コードを Misra に準拠させることは、それほど面倒なことではありません - かなり優れたプログラミング プラクティスに従えば。準拠させようとしているコードに奇妙で素晴らしいポインター演算が含まれている場合、ポインター規則のいくつかが少し難しいと感じるかもしれません。
私は PC Lint に対する Greg の推奨事項に 2 番目に賛成しますが、オープンソースの Splint も検討する価値があります。ただし、それら (およびコンパイラの警告システム) の間では、まだ Misra ルールの 80% しかカバーできないと推定されます。 - 残りはおそらく手動でコードをレビューする必要があります。
于 2008-09-15T13:55:23.250 に答える
4
私はCおよびC++コードの静的分析にPCLintを使用しています。違反したMISRAルールを表示するように構成でき、コマンドラインインターフェイスを備えています。
于 2008-09-15T13:47:16.080 に答える
3
QACという商用ツールを使用しました。このツールはMISRAを適用できます
コマンドライン インターフェイスがあるため、自動化されたビルド環境から実行するように設定できます。適用されるルールは構成可能ですが、誰かが時間をかけて設定することを期待してください。MISRA の適用は非常に簡単で、十分に機能しました。これは一部の機関 (FDA など) がコードを評価するために使用するツールの 1 つだと言われました (これは第三者にすぎません)。ほとんどの静的分析ツールと同様に、対処すべきノイズ (誤検知) があります。前回使用したときは、誤検知をマーク/再発防止する良い手段がありませんでした (文句を言っているコードを変更することなく)。
ジュニア エンジニアはセットアップに最大 1 週間 (4 ～ 5 日) かかると思います (彼らが希望どおりに動作させることを決意している場合)。
余談ですが、他の市販の静的分析ツールにも MISRA が適用されている可能性があります。伝えられるところによると (営業担当者によると)、Klocworkはそうしています。
于 2008-09-15T23:19:53.330 に答える
3
Misra のルールを後付けするという同様の問題がありました。大規模なプロジェクトでコード品質の問題が発生したため、MISRA を使用してコード品質を改善することにしました。
MISRA C ルールをサポートする Green Hills コンパイラを使用します。スタンドアロンのチェッカーも利用できます。やりたいことによっては、すべてのルールの切り替えが少し過剰になる可能性があります。限られた数の同様の問題を修正する時間を人々に与えるために、一度に 1 つのルールを有効にしました。
警告はスタンドアロン ツールではなくコンパイラによって生成されたものであるため、チェッカーを実行したときだけでなく、開発中にエラーが表示されます。開発を続けるうちに、コードをコンプライアントにすることができました。これにより、古い習慣によって新しいコードが台無しになり、後でコードを再度修正する必要がなくなります。
コードがどのように機能するかを正確に知っている人はいないため、古いコードに準拠させることが難しい場合があります。単体テストがあることを願っています。
于 2008-11-10T11:19:12.487 に答える
1
これが古い質問であることは理解していますが、他の考古学者 (または調査者) の利益のために、MISRA が提供するガイドラインは必ずしも盲目的に従うべきではないことを覚えておくことが重要です。
MISRA を念頭に置いて新しいコードを作成することをお勧めします。したがって、コンプライアンスを維持するのがはるかに簡単になります。
ただし、これは常に可能であるとは限りません。特に、ガイドラインを満たすためにコードをリバース エンジニアリングしようとする場合はそうです。この場合、必要なルールに焦点を当て、勧告をボーナスとして扱うことをお勧めします...コストとメリットがここにも適用されます!
また、逸脱プロセスがあることも念頭に置いてください。準拠しているが判読できないスパゲッティを考案するよりも、逸脱を伴うクリーンで保守可能なコードを維持する方が適切です。
于 2012-08-28T13:19:10.787 に答える