デバッグコードを常に残すか、常にデバッグするか、デバッグ時にのみ追加し、バグが見つかったときに削除する必要がありますか？

1つは、バグを特定するときにデバッグコード（printステートメントなど）を追加するだけです。そして、それを見つけたら、デバッグコードを削除します（そして、そのバグを具体的にテストするテストケースを追加します）。私はそれが実際のコードを乱雑にしているので、デバッグしていない限りそこに場所がないと感じています。

どうやってやるの？デバッグコードをそのまま残しますか、または廃止されたときにデバッグコードを削除しますか？

デバッグ出力ステートメントを削除する必要があります。ただし、本番環境の問題をデバッグするためにそれらを追加する必要がある場合は、ロギングフレームワークに十分な情報が含まれているかどうかを検討する価値があります。パラメータ、エラー状態などに関する情報は、次のバグが表示されたときに役立つ場合があります。デバッグまたはトレースログメッセージを動的に有効にすることができる適切なログフレームワークを使用することは、野生では非常に便利です。

デバッグ専用に追加されたコードは、本番ソフトウェアから削除する必要があります。

これが完全に削除されるか、条件付きコンパイルセクションに配置されるかは（C / C ++ / C＃のように）ユーザーとコーディング標準次第です。

これにはいくつかの理由があります。

1. このコードが実行されるか、誰かがその出力にアクセスできる場合、セキュリティに影響を及ぼす可能性があります。
2. アプリケーションの速度が低下する可能性があります。
3. 6か月後のコード（または実際に自分）を見る他の開発者にとって混乱するかもしれません。

ChrisFとAlaricの両方に有効なポイントがあります。+1。使用するデバッグコードの少なくとも5つの異なる種類を識別できます。

1. ログを使用して、特定の時点でシステム状態をダンプします。

   void function(...)
   {
       ...dump everything i know about.
   }
   

2. 実行チェックポイントにログを使用する。

   void function(...)
   {
       ...got here 1
       ...got here 2
   }
   

3. 特定の条件を実際に強制するが、通常の動作を中断するコード。例：

   • エラーに関するログがいくつかあるが、問題を再現できないとします。特定の変数に、ログ内の情報と一致する特定の値を強制するコードを作成してみてください。

4. 検証ログ-これを詳細なログとして分類します。これは、たとえばアルゴリズムの個々のステップを検証するなど、本番環境に含めるべきではないソフトウェアの正確性を検証するために使用できます。

5. 操作ログ-Alaricの投稿を参照してください。これが、「操作ログ」とはほぼ同じです。

1、2、3は完全に取り出す必要があります。4のようなものは、おそらく条件付きでコードからコンパイルするでしょう。5について、Alaricは動的にログをオフにできるという点で優れていました。これは、ほとんどの場合、ChrisFの 2番目の箇条書きのポイントに対応するものです。

それはコードが何をしているかに依存します。デバッグに使用される一部のコードはそのままにしておくことができ、一部は削除する必要があります。

メソッド内のパラメーターの健全性を検証するコードは、コードが適切に機能していれば必ずしも有用ではありませんが、多くの場合、コードが適切に機能し続けていることを確認します。

値を計算してローカル変数に格納するなど、コードのデバッグを容易にするためにコードを異なる方法で作成し、次の行で変数を使用すると、シングルステップ実行時に計算結果を簡単に確認できる場合がありますコードを通して。計算された値を直接使用するようにコードを書き換えることはできますが、ローカル変数を使用するコストは非常に小さいため（もしあれば）、コードを書き換える理由はほとんどありません。また、一度テストしたコードを変更せずにおくことにはポイントがあります。変更するときにバグを導入するリスクは常に小さいです。

特定のバグを追跡するためだけに追加したコードは、バグを発見した後に削除されることがよくあります。

昔々、私は多くのデバッグコードを使用していました。私はほとんど完全にWindowsを対象としていたので、このデバッグ文字列出力関数がたくさんあり、それ以上スペルを覚えていないので、特定のプログラムでトレースをキャプチャできました。

一部のデバッグコードはそのままで、特に呼び出しのネストを提供することを目的としたものです。ただし、デバッグ文字列はほとんど実稼働システムでは表示されませんが、条件付きコンパイルですべて実行されました。

しかし現実には、デバッグコードはすべて、理想的には異なる方法で処理されるもの（もちろん、デバッガーを使用する）に多大な労力を費やしたということです。当時、私はBorland C ++デバッガーにそれほど感動していませんでした。ツールはそこにありましたが、あまりにもしばしば誤解を招く結果をもたらし、非IDEデバッガーを使用することは（多くの場合必要でした）ショートカットキーを記憶することを意味し、手元の作業から気を散らすことを意味しました

最悪のデバッグ経験は、コマンドラインGDBだけです。

もちろん、毎日使用するツールの専門家であることは重要です。しかし、デバッグを毎日行うべきではありません。デバッガを頻繁に使用する場合、何十ものコマンドやキーボードショートカットを学習しても大丈夫です。

ただし、Visual Studio 7で作業していた頃には、デバッグが非常に実用的で効果的であることは明らかでした。Visual Studio（エクスプレスエディションを含む）でデバッグできる場合、デバッグは簡単です。適切なGUI / IDEフロントエンドを見つけることができれば、GDBも簡単で効果的ですが、まだその検索は行っていません。

また、gcovを使用したカバレッジ分析では、ユニットテストについても言及する必要があります。ライブラリの動作に自信があればあるほど、デバッグの深さは浅くなります-そもそもデバッガが必要になる頻度は少なくなります。そして、ユニットテストを書くことは、かなり合理的にあなたがほとんどの日するべきことです。

予想外に重要なツール= cmake。ビルドツールです。GCCとVC ++のビルドを簡単に切り替えることができます。そのため、GCCを使用してユニットテストとgcovベースのカバレッジを実行できますが、VC ++に簡単に切り替えてデバッガーを使用できます。

私の考え：問題のコード内のバグを殺すために使用されるデバッグコードは、私は一般的に完全に削除します。外部の力に起因するバグを殺すために使用されるデバッグコードは、一般的にコメントアウトします。

バグが単体テストまたは内部にある場合、デバッグコードは完全に削除できます。しかし、バグが本番のものである場合、デバッグコードはコンパイルタグ内にある方が適切です。コンパイルタグ内に配置することで、他の開発者はこのコードがデバッグ目的のみであることを理解するのに役立ちます。

TDDを使用して、テストコードが常に維持される場所があるようにします。