6

私はいくつかの Windows アプリケーション用に大規模な C++ コードベースを継承しており、多くの顧客によって正常に使用されています。

  • コードベースは大きく、LOC は 100 万を超えます。
  • コードベースには 15 年以上の歴史があります。
  • コードベースは、C プログラミング スタイルやあまり現代的ではない C++ スタイル (標準 C++ コレクションとアルゴリズムを使用していないなど) によって支配されている領域があります。
  • 残念ながら、コードベースは警告レベル 2 (Visual C++ では /W2) でしかコンパイルされていません。レベル3(/W3)に上げてセキュリティを上げて64ビットに備えたい。

警告レベル 3 への引き上げで最も問題となるのは、署名付き/未署名の不一致に関する多数の警告であり、既存のコードベースでそれらをすべて解決することは非常に大きな作業になると認識しています。

コードベースにコミットされた新しいコードが警告レベルを上げてコンパイルされるようにするための適切なアプローチは何でしょうか?

より一般的な言葉で言えば、この質問は、新しいコミットされたコードに向上したプログラミングの品質をどのように適用するかという質問に言い換えることができます。何もしなければ、新しいコードは、私の経験では、より現代的な標準に改善されるのではなく、影響を受け、既存のコードと同様のスタイルになる傾向があります。

4

6 に答える 6

3

警告レベル4（/ W4）まで行きます。

Visual Studioを使用しているので、符号付きと符号なしの比較などの厄介な警告を簡単に抑制できます。

#pragma warning(disable:NNNN)

NNNN警告の番号はどこにありますか。次に、これらの無効な警告をすべてヘッダーファイル（「tedious_warnings.h」など）に入れ、そのヘッダーファイルをどこにでも強制インクルードします-プロジェクトプロパティ-> C /C++->詳細設定->強制インクルードファイル。
後で、またはより良い方法として、フォースインクルードを削除し、警告を処理します。警告のほとんどは非常に簡単に修正できるためです（size_t代わりintになど）。

于 2011-05-16T08:50:33.503 に答える
2

おそらく、別の DLL またはライブラリで新しいコードを作成できます。そうすれば、古いコードからの何千もの警告を通り抜ける必要なく、より高い警告レベルを強制することができます (そして、/W3 に落ち着くのではなく、/W4 に行き、MS の dafter 警告のいくつかをオフにする準備ができていると思います)。

その後、時間があるときに古いコードを少しずつクリーンアップする作業を開始できます。もちろん、誤ってコードを壊してしまわないように、適切な単体テストが適切に行われていることを確認してください。

于 2011-05-16T08:46:48.250 に答える
1

あなたは答えが気に入らないかもしれません...

問題を修正して警告を削除します。

私は警告レベルについて非常にうるさいです。特に警告レベルが高く、ビルド時間が長い場合は、修正する必要のない警告を無視します。その間、新しいものは（大きなコードベースで）滑り込みます。私の経験では、それらを段階的に削除することはあまりうまく機能しません-ノイズが高すぎるか、強制されていない場合、それらは無視される傾向があります。

人々が追加した警告を（あなたが望む警告レベルで）見ることができるように、警告ノイズを減らす必要があります。

必要な/必要なコンプライアンスレベルに到達するには、それを優先します。

変換/比較が有効かどうかわからない場合は、エラーアクション（アサート、スロー、ログ）を含むテンプレート関数をいつでも使用して、疑わしいときにロジックを実行できます。

時間がかかる/面倒なプロセスになる可能性がありますが、コードベースを学習するための良い方法でもあります。

私は通常、ツリーの最上位のライブラリ、または最も頻繁に再利用されるライブラリから始めます。ライブラリが基準を満たしたら、その基準を維持します。

于 2011-05-16T08:59:40.947 に答える
0

私のアプローチは、可能な限り最高の警告レベルを使用して、発生するすべての警告を修正することでした。プロセス中にいくつかのバグが見つかる場合もあります。

すべてのプロジェクトが同じ警告レベルでコンパイルされ、これらの設定に加えた変更がすべてのプロジェクトで変更されるvspropsように、ファイルを使用してこれを設定する必要があります。

より段階的なアプローチは、可能な限り最高の警告レベルを使用して、ほとんどすべての警告を無効にし、一度に考慮すべき警告の数を少なくすることです。それらを修正してから、別の警告をオンにします。警告なし。

于 2011-05-16T10:01:35.890 に答える
0

新しいより厳しい警告レベルの結果としてコードを変更する場合は、新しい問題やバグの発生を防ぐ適切なテストを作成してください。新しい警告レベルを使用してテストを記述します。コードベースの変更を開始し、正しい機能を確認する前に、これを実行してください。次に、同じテストケースに対して更新されたコードを再実行できます。

于 2011-05-16T08:58:14.503 に答える
0

私は増分アプローチを使用します。

最初のステップは、古いファイルを変更pragmaし、コード内の警告を無効にするために必要なアクションを追加することです。

2 番目のステップは、「古い」警告をすべて破棄する特定のプラグマ パターンを含むコミットされたファイルを拒否するコミット フックを作成することです。

これは、変更されたファイルに警告がないことを意味します。

ただし、率直に言って、開発者は常にシステムを操作する方法を見つけます。

于 2011-05-16T09:16:28.720 に答える