2

最近、 Debug クラスについてよく読んでいます。

私は個人的にそれについてかなり引き裂かれています。非常にトリッキーなアルゴリズムを作成するプロセスが改善されていることがわかります。しかし、アプリに多くのコードが追加され、不必要に苦労する必要があります。デバッガーを使用すると、定型コードの必要性がなくなるはずです。リリース ビルド用に自動的に削除されるかどうかに関係なく、そうではありませんか?

また、Debug クラスを有効に活用している皆さんがどのようにそれを行っているかにも興味があります。Debug.Assert ステートメントを作成しますか、それとも Debug.WriteLine と Debug.Fail だけを使用する必要があるというEd Kaim の意見に同意しますか。

4

8 に答える 8

3

私は個人的に Ed Kaim に同意します。個人的には、すべての作業において、良いテスト プラクティスが Debug.Assert 呼び出しに取って代わったと感じています。さらに、Debug.Fail の使用もほとんど放棄しました。これを使用したいときはいつでも、デバッグだけでなくリリースでも例外をスローしたいことがほとんどなので、通常は表示されません。ポイント。

そうは言っても、特に数値コードでは、デバッグを強化するために(Debug.WriteLineを介して)デバッグ印刷ステートメントの一部を使用しています...古い学校のprintfデバッグへの逆戻りであることは認めますが、多くの場合、それはまだです問題、特にデバッガーに表示されない問題 (タイミングの問題、スレッド化など) を追跡する最速の方法です。

于 2009-07-09T15:51:47.150 に答える
2

個人的には、プログラミングで Debug クラスを使用することはほとんどありません。John Robbins ( Debugging .NET 2.0 ApplicationsおよびBugslayerコラムの著者) による、積極的にアサートする必要がある理由 (特にメソッドのパラメーター)など、多くのコメントや提案を読みました。

私が抱えている問題はこれです-次のようなコードを書くとしましょう：

Public Sub Test(source As Object)

  Debug.Assert(source IsNot Nothing, "source is Nothing")

  ' Do something....
End Sub

これは、デバッグ ビルドを使用した開発中にうまく機能しますが、とにかくこれを行うことになります。

Public Sub Test(source As Object)

  If source IsNot Nothing Then

  ' Do something....

  End If
End Sub

「ソース」が何もない可能性がある場合は、とにかく「If」チェックを行います。リリース ビルドに assert 呼び出しを残すつもりはありません。

Debug クラスを使用しないもう 1 つの理由は、多くの単体テストを作成するためです。そうすることで、多くのコード パスをカバーするようになり、コードに Debug.Assert を含める必要がなくなりました。

デバッグ ログについては、Trace 呼び出しと SysInternals DebugView またはテキスト ファイルを使用して、トレース呼び出しの出力をログに記録します。

開発中に Debug クラスをどのように使用しているかについても知りたいので、このトピックについて他の人から聞いてみたいです。あまり経験のない分野なので、ぜひ学んでいきたいです。

于 2009-07-09T16:04:05.753 に答える
1

Debugクラスをまったく使用しないことをお勧めします。私はしません。一般的に、開発では、デバッガーが私のすべてのニーズに十分対応できることがわかります。そして、私が本当に追跡する必要があるものをログに記録します。ロギングに関する最も重要な部分は、ロギングが本番コードでも発生することです。これは絶対に重要です。 Debug定義上、デバッグコードでのみ機能します。開発中に何かを見つけるのに役立つかもしれませんが、見つけることが重要な場合は、ログに記録してください。真剣に。見つけることが重要で、それに到達するために特別な機能が必要になるほどトリッキーな場合は、ログに記録します。実稼働環境ではエッジケースとして表示される可能性がありますが、その場合はどうしますか？

そして、その価値については、log4netがロギングの目的で非常に便利で堅牢であることがわかりました。Debugいつでもクラスの使用よりも使用することをお勧めします。

于 2009-07-09T17:10:52.483 に答える
1

私自身の意見では、Debug.Assert と Debug.Fail は、エンド ユーザーからエラーを「隠す」ために悪用されることがよくあります。エラーログに書き込むか、保証されている場合は例外をスローします。

于 2009-07-09T16:12:57.327 に答える
1

必要かどうかはわかりませんが、使用するタイミングを提案できます。

関数/変数/プロセス/結果に関する詳細情報が必要な場合はデバッグを使用しますが、リリースされると、その情報はもはや関連性がないことがわかります。たとえば、Debug.Writeline を使用してプロセスの正しい年表を確認したり、Debug.Assert を使用して値が本来あるべき値であることを確認したりします。

Kaim は、Debug.Assert を誤用しやすいと言っているだけだと思います。本番環境で発生する可能性のある問題をキャッチするために Debug.Assert を使用しないでください。Debug.Assert は、リマインダー フラグのように、開発中の簡単なチェックを目的としています。リリース コード エラーを処理するためのものではありません。Debug.Assert を 1 行おきに配置しても、リリース コードの速度が低下することを心配する必要はありません。

于 2009-07-09T16:17:04.150 に答える
1

デバッガーで単純にコードを実行するよりも Debug クラスを使用する主な利点は、(Debug.Writeline ステートメントを使用して) ログ ファイルを取得できることです。ログ ファイルは、同僚と共有したり、記録用に保存したりできます。

Debug.Assert が別のテスト メソッドを記述するよりも優れている点は、コンパクトであることと、チェックが別のメソッドではなく必要な場所に正確にあるという事実です。

于 2009-07-09T16:02:42.213 に答える
0

コントラクトの Debug.Assert テスト。リリース コードに含まれていないという利点があります。if + throwing exception ケースの場合はそうではありません。

デバッガーが邪魔になるため、UI イベントに Debug.WriteLine を使用します (たとえば、VS ウィンドウからアプリ ウィンドウに切り替えると、更新イベントが再度呼び出されます)。

于 2009-07-09T15:59:47.900 に答える
0

私たちは Debug.Assert を非常に頻繁に使用します。Assert を使用しても害はないという重要な仮定があるためです。

非常に便利だが古い記事 - IDesign C# Coding Standards here

于 2009-07-09T15:53:33.497 に答える