静的コード分析

翻訳者からのメモ 。 この記事はもともとAltDevBlogADayウェブサイトで公開されました。 しかし、残念ながらこのサイトは存在しなくなりました。 1年以上にわたり、この記事は読者がアクセスできないままです。 私たちはジョン・カーマックに目を向け、彼はこの記事を私たちのウェブサイトに投稿しても構わないと言った。 喜んでやった。 Wayback Machine-Internet Archive： Static Code Analysisを使用して、元の記事に慣れることができます。



ウェブサイト上のすべての記事はロシア語と英語で表示されているため、静的コード分析の記事をロシア語に翻訳しました。 そして同時に、それをHabréで公開することにしました。 この記事の改定は、すでにここで公開されています。 しかし、私は多くの人が翻訳を読むことに興味があると確信しています。



近年のプログラマとしての私の主な成果は、静的コード分析の方法とそのアクティブなアプリケーションに精通していることです。 おかげでコードで許可されなかった何百もの重大なバグの問題ではなく、ソフトウェアの信頼性と品質の問題に関する私のプログラミングの世界観におけるこの経験によって引き起こされた変化の問題です。



すぐにすべてを品質に落とすことはできず、それを認めることは、自分の道徳原則を裏切ることを意味しないことに注意してください。 全体として作成する製品には価値があり、コードの品質は、コスト、機能、およびその他の特性とともに、そのコンポーネントの1つにすぎません。 世界は多くの成功し、尊敬されているゲームプロジェクトを知っています。バグが詰め込まれ、際限なく落下します。 また、スペースシャトルソフトウェアを作成するのと同じ深刻さでゲームの作成に取り組むのは愚かなことです。 それでも、品質は間違いなく重要な要素です。



私はいつも良いコードを書こうとしました。 私の性質上、私は何かを継続的に改善したいという欲求に駆られている職人のように見えます。 「戦略、標準、品質計画」のような退屈な章のタイトルが付いた本を山ほど読み、アルマジロエアロスペースで働くことは、以前の経験とはまったく異なる、高度なセキュリティ要件を備えたソフトウェア開発の世界への道を開きました。



10年以上前、Quake 3を開発していたとき、PC-Lintのライセンスを購入し、それを自分の仕事に適用しようとしました。コードの欠陥を自動的に検出するというアイデアに魅了されました。 ただし、コマンドラインから実行し、診断メッセージの長いリストを表示する必要があるため、このツールを使用することを思いとどまり、すぐにそれを放棄しました。



それ以来、プログラマの数とコードベースのサイズの両方が桁違いに大きくなり、プログラミングの重要性がCからC ++にシフトしました。 これはすべて、プログラムエラーの道を開きました。 数年前、最新の静的コード分析に関する科学記事を読んだ後、PC-Lintを使ってみてからこの10年でこの分野の状況がどのように変化したかを確認することにしました。



当時、私たちのコードは第4レベルの警告でコンパイルされていましたが、高度に専門化された診断はわずかしかオフになっていませんでした。 このアプローチ-すべての警告をエラーとして処理すること-プログラマは、このポリシーを厳守することを余儀なくされました。 そして、私たちのコードでは、「ゴミ」が長年にわたって蓄積したいくつかのほこりだらけのコーナーを見つけることができましたが、一般的には非常にモダンでした。 かなり良いコードベースがあると思いました。

コベリティ

それはすべて、私がCoverityに連絡し、ツールを使用してコードのトライアル診断にサインアップしたという事実から始まりました。 これは深刻なプログラムであり、ライセンスのコストはコードの合計行数に依存し、5桁の数値で表される価格に決めました。 Coverityの専門家は、分析結果を表示して、私たちのベースが、見てきたすべての「重量カテゴリ」の中で最もクリーンなものの1つであることに気づきました（おそらく、すべての顧客にこれを言って励まします）約100の問題領域が含まれています。 このアプローチは、以前のPC-Lintの経験とは大きく異なりました。 この場合の信号対雑音比は非常に高いことが判明しました。コベリティによって発行された警告のほとんどは、重大な結果をもたらす可能性のある明らかに誤ったコードセクションを示していました。



このケースは文字通り静的分析に目を向けましたが、すべての喜びが高額だったため、しばらくの間楽器を購入できませんでした。 リリースまで残ったコードでは、多くのエラーは発生しないと考えました。

マイクロソフト/分析

最終的にはCoverityを購入することを決めた可能性がありますが、それについて考えている間、Microsoftは360 SDKに新しい/分析機能を実装することで疑問を解消しました。 / Analyzeは、以前は非常に高価なバージョンのVisual Studioのコンポーネントとして利用可能でしたが、その後、突然xbox 360のすべての開発者に無料で提供されました。私が理解しているように、Microsoftの360番目のプラットフォームのゲームの品質は、Windowsのソフトウェアの品質以上です :-)



技術的な観点から見ると、Microsoftアナライザーはローカル分析のみを実行します。 Coverityのグローバル分析には劣りますが、有効にすると、大量のメッセージが投げかけられました。Coverityが伝えた以上のものです。 はい、多くの誤検知がありましたが、それらがなくても、かなりの恐ろしい、本当にひどい金銭がありました。



私はゆっくりとコードの編集を始めました。まず、自分のシステムを、次にシステムを、そして最後にゲームを取り上げました。 私は自由に仕事をしなければならず、自由な時間に始めたので、プロセス全体が数ヶ月続きました。 ただし、この遅延には副次的な有益な効果もありました。つまり、/分析が重要な欠陥を本当にキャッチすると確信していました。 実際、編集と同じように、開発者はバグの数日間にわたる長い狩りを手配し、すでにフラグが付けられ/分析されているが、まだ修正されていないエラーの痕跡を攻撃するたびに判明しました。 さらに、デバッグにより、既にマーク/分析されたコードに至った、それほど劇的ではない他のケースがありました。 これらはすべて本当の間違いでした。



最終的に、使用するすべてのコードが360プラットフォーム用の実行可能ファイルにコンパイルされ、/ analyzeが有効になっているときに警告が1つも表示されないようにし、このコンパイルモードを360ビルドの標準として設定しました。 その後、同じプラットフォームで作業する各プログラマーのコードは、コンパイル中に毎回エラーがチェックされたため、後で対処する代わりに、プログラムに導入されたバグをすぐに修正できました。 もちろん、このため、コンパイルプロセスは多少遅くなりますが、/ analyzeは、私が対処し、信頼しなければならない最速のツールです。



あるプロジェクトで、誤って静的分析をオフにしました。 数ヶ月が経過し、これに気づき、再び有効にすると、ツールはこの間にコードに加えられたエラーに関する多数の新しい警告を発行しました。 同様に、PCまたはPS3でのみ作業するプログラマーは、リポジトリにエラーコードを入力し、「失敗した360ビルド」に関するレポートが記載された手紙を受け取るまで無知のままになります。 これらの例は、日々の活動の中で、開発者が特定のタイプのミスを何度も繰り返し、/分析することでほとんどの人から確実に救われたことを明確に示しています。



ブルースドーソンは彼のブログで繰り返し仕事/分析に言及しました 。

PVS-Studio

360コードでのみ使用/分析できるため、コードベースの大部分はまだ静的分析でカバーされていませんでした-これは、PCおよびPS3プラットフォーム、およびPC上でのみ実行されるすべてのプログラムのコードに関するものです。



次に出会ったツールはPVS-Studioでした。 Visual Studioと簡単に統合でき、便利なデモモードがあります（自分で試してみてください！）。 /分析と比較して、PVS-Studioは非常に遅いですが、ビュー/分析の観点からすでに完全にクリーンアップされたコードでも、いくつかの新しい重大なバグをキャッチすることができました。 明らかなエラーに加えて、PVS-Studioは他の多くの欠陥をキャッチします。これは、通常のコードのように見えますが、誤ったプログラマーの決まり文句です。 このため、一定の割合の誤検知はほとんど避けられませんが、そのようなパターンはコード内で見つかり、修正しました。



PVS-StudioのWebサイトでこのツールに関する多数の素晴らしい記事を見つけることができます。多くの記事には、記事で説明されているエラーの種類を具体的に示す実際のオープンソースプロジェクトの例が含まれています。 ここにPVS-Studioによって発行されたいくつかの診断メッセージを挿入することを考えていましたが、もっと興味深い例がすでにサイトに登場しています。 そのため、ページにアクセスして、自分の目で確かめてください。 そして、はい-これらの例を読むとき、にやにやして、決して書かないと言ってはいけません。

PC-Lint

最後に、開発環境に統合するために、 Visual Lintと組み合わせてPC-Lintを使用するオプションに戻りました。 Unixの世界の伝説的な伝統に従って、このツールはほとんどすべてのタスクを実行するように構成できますが、そのインターフェースはあまり使いやすくなく、開始して実行することはできません。 5つのライセンスセットを購入しましたが、その開発には非常に時間がかかり、私の知る限り、他のすべての開発者は最終的にそれを放棄しました。 柔軟性には本当に利点があります-たとえば、PS3プラットフォームのすべてのコードをテストするように構成できましたが、多くの時間と労力がかかりました。



また、分析/ PVS-Studioの観点から既にクリーンなコードで、新しい重要なエラーが見つかりました。 私は正直、糸くずが誓わないように掃除しようとしましたが、失敗しました。 システムコード全体を修正しましたが、ゲームコードで彼が発行した警告の数を見たときにgaveめました。 エラーをクラスに分類し、最もクリティカルなものに対処し、文体的な欠陥や潜在的な問題に関連する他の人の質量を無視しました。



私は、PC-Lintの観点から膨大な量のコードを最大限に修正しようとすると、明らかに失敗する運命にあると信じています。 わずらわしいすべての「リント」コメントを素直に取り除こうとした場所にコードを一から作成しましたが、ほとんどのC / C ++プログラマーにとって、エラーに取り組むこのアプローチはすでに多すぎます。 最適な警告を見つけてツールを最大限に活用するには、PC-Lint設定をいじる必要があります。

結論

これらすべてを経験することで多くのことを学びました。 短時間で何百ものエラーメッセージを個人的に分析する必要がなく、それらを修正し始めたときに頭がおかしいと感じるたびに、結論の一部を受け入れることが難しくなり、私の言葉に対する標準的な反応は「まあ、すべてが順調に並んでいる、または「すべてがそれほど悪くない」



このパスの最初のステップは、コードにバグがたくさんあることを正直に認めることです。 ほとんどのプログラマーにとってこれは苦い薬ですが、飲み込むことなく、いらいらしたり、偽装された敵意を持ってコードを変更したり改善したりする提案を必ずとるでしょう。 あなたのコードを批判したいはずです 。



自動化が必要です。 自動システムでの大規模な障害のレポートを見ると、ある種の栄光を経験することは不可能ですが、自動化のあらゆるミスには、多くの人為的エラーがあります。 「より良いコードを書く」、より多くのコード検査セッションを実施する意図、ペアプログラミングなどの要求は、特に何十人もの人々がプロジェクトに関与していて、あなたが大急ぎで働かなければならないとき、単に働きません。 静的解析の大きな価値は、実行ごとにこの手法で利用可能なエラーの少なくとも小さな部分を見つける能力にあります。



PVS-Studioが更新されるたびに、新しい診断のおかげでコードにエラーが増えていることに気付きました。 このことから、コードベースが特定のサイズに達すると、構文の観点から許容されるすべてのエラーが表示されるように思えます。 大規模なプロジェクトでは、コードの品質は物質の物理的特性と同じ統計的法則に従います-その欠陥はどこでも一般的であり、ユーザーへの影響を最小限に抑えることができます。



静的分析ツールは、「片手で縛られて」動作することを余儀なくされます。それらは、そのような結論に情報を必ずしも提供しない言語の分析に基づいて結論を導き出さなければなりません。 したがって、可能な限りアナライザーを支援する必要があります-ポインターを使用した算術演算よりもインデックス付けを優先する、コールグラフを単一のソースファイルに保持する、明示的な注釈を使用するなど 静的アナライザーにとっては自明でないと思われるものは、ほぼ間違いなくあなたの仲間のプログラマーを混乱させます。 厳密な静的型付けを使用する言語（「ボンデージ言語と規律言語」）に対する特徴的な「ハッカー」嫌悪は、実際には近視眼的です。



ヌルポインターは、少なくとも私たちにとって、C / C ++で最も差し迫った問題です。 フラグとアドレスの両方として単一の値を二重に使用すると、非常に多くの重大なエラーが発生します。 したがって、可能な場合は常に、C ++はポインターではなくリンクを優先する必要があります。 「実際」のリンクは同じインデックスにすぎませんが、ゼロに等しくすることは不可能であるという暗黙の義務に拘束されます。 リンクに変わったら、ポインタをゼロにチェックします-これにより、この問題を後で忘れることができます。 ゲームの分野では、潜在的な危険を伴う多くの根深いプログラミングパターンがありますが、ゼロチェックからリンクに完全かつ簡単に切り替える方法はわかりません。



コードベースで2番目に重要な問題は、printf関数のエラーです。 さらに、idStr :: c_str（）の代わりにidStrを渡すと、ほとんど常にプログラムがクラッシュするという事実によってさらに悪化しました。 ただし、型チェックが正しく実行されるように、可変数の引数を持つ関数の注釈を使用/分析し始めたとき、問題は完全に解決されました。 アナライザーの有用な警告では、対応するコードブランチを開始するために何らかのエラー状態が発生した場合にクラッシュを引き起こす可能性のあるこのような欠陥が多数見られました。これは、テストによるコードのカバレッジの割合がどれだけ小さいかを示しています



アナライザーが報告した重大なバグの多くは、作成されてからずっと後に行われたコード変更に関連しています。 信じられないほど一般的な例は、操作の前にポインターが以前ゼロにチェックされていた理想的なコードがその後変更され、ポインターがチェックなしで突然使用されるようになった場合です。 この問題を単独で考えると、コードの高い循環的複雑さについて不平を言うことができますが、プロジェクトの履歴を見ると、コードの作成者が、後でリファクタリングの責任を負うプログラマーに前提を明確に伝えることができなかったことがわかります。



定義上、人はすべてに一度に注意を向けることができないため、まず第一に、顧客に提供するコードに焦点を合わせ、内部ニーズのコードにあまり注意を払いません。 内部プロジェクトへの販売を目的としたデータベースからコードを積極的に転送します。 最近、その多様性におけるコード品質のすべてのメトリックがコードのサイズとエラーレートとほぼ完全に相関し、エラーの数だけを高精度で予測できるという記事が公開されました。 そのため、品質の点で重要なコードの部分を削減します。



並列プログラミングに伴うこれらすべての追加の困難の中心に怖がっていないのであれば、この問題を適切に掘り下げていないように思われます。



ソフトウェア開発中に信頼性の高い制御テストを実施することは不可能ですが、コード分析の使用による成功は非常に明確であったため、コード分析を使用しないことは無責任です！ クラッシュに関する自動コンソールログには、多くの点で先駆者であるRageでさえ、ほとんどの最新のゲームよりもはるかに安定的で健康的であることが明らかになった客観的データが含まれています。 残念ながら、PCでのRageの起動は失敗しました。AMDはグラフィックドライバーの開発時に静的解析を使用していないと思います。



既製のレシピは次のとおりです。VisualStudioのバージョンに組み込み/分析がある場合は、それを有効にして、このように動作させてください。 多くのツールのいずれかを選択するように求められた場合、Microsoftからのこの特定の決定を検討します。 Visual Studioで作業する他のすべての人は、少なくともPVS-Studioをデモモードで試すことをお勧めします。 商用ソフトウェアを開発している場合、静的分析ツールを入手することが投資の最良の方法の1つになります。



最後に、Twitterからのコメント：



Dave Revell @dave_revellコードで静的解析を使用すればするほど、コンピューターがどのように起動するのか不思議に思うようになります。