IDEでのデバッグが優れているのはなぜですか？
私は、C、Perl、SQL、Java、PHP、JavaScript、そして最近Pythonでプログラミングを行って20年以上ソフトウェア開発者です。慎重に考えてデバッグできない問題が発生したことはなく、適切に配置されたprintステートメントをデバッグしました。
私のテクニックは原始的であると多くの人が言っていることを尊重し、IDEで実際のデバッガーを使用する方がはるかに優れています。しかし、私の観察から、IDEユーザーは、石刀と熊の皮を使用して、私ができる以上に速くまたはよりうまくデバッグできないようです。適切なツールを学ぶことに心を開いています。ビジュアルデバッガーを使用することの魅力的な利点を示したことがありません。
さらに、ブレークポイントを設定して変数の内容を表示する方法の基本を超えて、IDEを使用して効果的にデバッグする方法を示したチュートリアルや本を読んだことがありません。
私は何が欠けていますか？ IDEデバッグツールが、診断printステートメントの思慮深い使用よりもはるかに効果的なのはなぜですか？
IDEデバッグのより優れた手法を示すリソース（チュートリアル、書籍、スクリーンキャスト）を提案できますか？
甘い答え！お時間を割いてくださり、ありがとうございます。非常に明るくなります。私は多くの票を投じたが、何も下がらなかった。
注目すべき点：
- デバッガーは私を助けることができますアドホック変数、コード、またはランタイム環境の他の側面の検査または変更、手動デバッグではアプリケーションを停止、編集、再実行する必要があります再コンパイル）。
- デバッガーは実行中のプロセスにアタッチするか、クラッシュダンプを使用できますが、手動デバッグでは「再現する手順」で欠陥が必要です。
- デバッガーは、複雑なデータ構造、マルチスレッド環境、または完全なランタイムスタックを簡単かつ読みやすい方法で表示できます。
- デバッガーは、ほとんどすべてのデバッグタスクを実行するための時間と反復作業を減らすための多くの方法を提供します。
- ビジュアルデバッガーとコンソールデバッガーはどちらも便利で、多くの機能が共通しています。
- IDEに統合されたビジュアルデバッガーを使用すると、単一の統合開発環境（名前の由来）で、スマート編集やIDEのその他すべての機能に簡単にアクセスできます。
IDEデバッガーがコード内のトレースメッセージを上書きするいくつかの機能の例：
- call stackをいつでも表示して、現在のスタックフレームのコンテキストを確認できます。
- ライブラリにステップイントレースを追加する目的で再コンパイルできない（デバッグシンボルにアクセスできると仮定）
- 変数値の変更プログラムの実行中
- 編集して続行-実行中にコードを変更するで、変更の結果をすぐに確認する機能
- watch変数を使用して、変数がいつ変更されるかを確認できる
- コードのセクションをスキップまたは繰り返すを実行して、コードの実行方法を確認できます。これにより、理論的な変更を行う前にテストすることができます。
- メモリの内容をリアルタイムで調べる
- 特定の例外がスローされた場合、それらがアプリケーションによって処理されていても警告します。
- 条件付きブレークポイント;例外的な状況でのみアプリケーションを停止して、スタックと変数を分析できるようにします。
- スレッドコンテキストをマルチスレッドアプリケーションで表示します。これは、トレースでは実現が困難な場合があります（異なるスレッドからのトレースが出力でインターリーブされるため）。
要約すると、印刷ステートメントは（一般的に）staticであり、元のステートメントが十分に詳細でない場合、追加情報を取得するために再コンパイルする必要があります。 IDEはこの静的な障壁を取り除き、指先でdynamicツールキットを提供します。
最初にコーディングを始めたとき、デバッガーの大したことを理解できず、トレースで何でも達成できると思っていました（確かに、それはUNIX上にあり、デバッガーはGDBでした）。ただし、グラフィカルデバッガーを適切に使用する方法を学習した後は、printステートメントに戻りたくありません。
IDEデバッガーを使用すると、実行時に変数の値を変更できます。
IDEデバッガーを使用すると、実行がいつ開始されたかを知りたいと思わなかった変数の値を確認できます。
IDEデバッガーを使用すると、コールスタックを表示し、渡された奇妙な値の関数の状態を調べることができます（この関数は何百もの場所から呼び出されるため、これらの奇妙な値は、から来る）
IDEデバッガーを使用すると、行番号ではなく条件に基づいて、コードの任意のポイントで条件付きで実行を中断できます。
IDEデバッガーは、単に処理するのではなく、未処理の例外の場合にプログラムの状態を調べることができます。
「print」ステートメントでは間違いなくデバッグできないことが1つあります。これは、顧客がメモリダンプを持ち込み、「プログラムがクラッシュしました。理由を教えていただけますか？」
- すべてのコードでステートメントを印刷すると、可読性が低下します。
- デバッグ目的でのみそれらを追加および削除するには時間がかかります
- デバッガーは呼び出しスタックを追跡し、現在地を簡単に確認できます
- 変数はその場で変更できます
- 実行の一時停止中にアドホックコマンドを実行して、診断を支援できます。
- CONJUNCTIONとprintステートメントで使用できます：Debug.Write（ "..."）
Print文を使用したデバッグは失われた芸術であり、すべての開発者が学ぶことが非常に重要だと思います。その方法を理解すると、特定の種類のバグは、IDEを使用するよりもデバッグがはるかに簡単になります。この手法を知っているプログラマーは、非デバッグ目的でも、ログメッセージに書き込むのに役立つ情報（実際にログを読むことになるのは言うまでもありません）を非常によく感じています。
とはいえ、異なるクラスのバグの場合は非常に簡単なので、ステップスルーデバッガーの使用方法を実際に知っておく必要があります。理由を説明するために、すでに投稿されている他の優れた回答にお任せします:)
私の頭の上から：
- 複雑なオブジェクトのデバッグ-デバッガーを使用すると、オブジェクトの内部に深く入り込むことができます。たとえば、オブジェクトが複雑なオブジェクトの配列の配列を持っている場合、printステートメントはこれまでのところ取得するだけです。
- 過去のコードをステップ実行する機能-デバッガーでは、実行したくない過去のコードをスキップすることもできます。確かに、これを手動で行うこともできますが、注入する必要があるコードははるかに多くなります。
IDEでデバッグする代わりに、すばらしいGoogleを試すことができますChrome拡張機能 PHPコンソール with php library 次のことができます。
- Chrome JavaScriptコンソールおよび通知ポップアップでエラーと例外を参照してください。
- 型変数をダンプします。
- PHPコードをリモートで実行します。
- パスワードでアクセスを保護します。
- 要求ごとにコンソールログをグループ化します。
- テキストエディタでエラーファイル：行にジャンプします。
- エラー/デバッグデータをクリップボードにコピーします（テスター用）。
私は20年近くも開発していませんが、IDE /デバッガーを使用すると次のことができます：
- 印刷文に含まれているとは思わなかったあらゆる種類のものを見る
- コードをステップ実行して、それが取ると思ったパスと一致するかどうかを確認します
- 変数に特定の値を設定して、コードに特定のブランチを作成させる
IDEを使用する理由の1つは、最新のIDEが単純なブレークポイント以上のものをサポートしているためかもしれません。たとえば、Visual Studioは次の高度なデバッグ機能を提供します。
- 条件付きブレークポイントを定義します（条件が満たされた場合のみブレークするか、ブレークポイントのステートメントが実行されるn回目にのみブレークします）
- 未処理の例外で、または（特定の）ecxeptionがスローされるたびにブレークする
- デバッグ中に変数を変更する
- 実行する次の行を設定してコードを繰り返します
- 等.
また、デバッガーを使用する場合、デバッグが完了したら、すべてのprintステートメントを削除する必要はありません。
私が別の答えで見たことがないことに驚いたことの1つは、2つのデバッグ方法が相互に排他的ではないであることです。
printfデバッグは、標準のデバッガを使用している場合でも（IDEベースかどうかに関係なく）非常にうまく機能します。特にロギングフレームワークの場合、すべてまたはほとんどを残すことができます。顧客の問題の診断を支援するために、リリースされた製品に含まれています。
他のほとんどすべての回答で述べたように、標準デバッガーの重要な利点は、プログラム状態の詳細をより簡単に検査（および変更）できることです。あなたが何を見たいかを前もって知る必要はありません-それはすべてあなたの指先で利用可能です（多かれ少なかれ）。
私の経験では、単純な印刷には、誰も言及していないような大きな利点があります。
IDEデバッガの問題は、すべてがリアルタイムで発生することです。特定の時間にプログラムを停止してから、一度に1ステップずつ実行し、次の場合に戻ることはできません。突然、前に何が起こったのかを見たいと思います。これは、私たちの脳がどのように機能するかと完全に矛盾しています。脳は情報を収集し、徐々に意見を形成します。一定のポイントを過ぎると、戻ることができません。
これとは対照的に、選択された一連の印刷/ログ記録は、「一時的なイベントの空間的投影」を提供します。何が起こったのか完全なストーリーを提供します。上下にスクロールするだけです。「Bが発生する前にAが発生した」などの質問に簡単に答えることができます。探しているパターンも確認できます。
だから私の経験では。 IDEとデバッガーは、単一の呼び出しスタックで何かがうまくいかなかった場合の単純な問題を解決し、特定のクラッシュでのマシンの現在の状態を調べる素晴らしいツールです。
ただし、段階的な状態の変化が関係するより困難な問題に取り組む場合。たとえば、あるアルゴリズムがデータ構造を破壊した場合、それにより、他のアルゴリズムが失敗しました。または、「これはどのくらいの頻度で発生するか」、「物事が発生する順序で、私が想像するとおりに発生する」などの質問に答えたい場合です。など。その後、「昔ながらの」ロギング/プリントアウト技術には明らかな利点があります。
最良の方法は、最適な場合にいずれかの手法を使用することです。たとえば、ロギング/プリントアウトを使用してバグを見つけ、現在の状態をより詳細に調べる必要があるブレークポイントで一時停止します。
ハイブリッドアプローチもあります。たとえば、console.log（object）を実行すると、ログにデータ構造ウィジェットが表示されます。このウィジェットは、詳細に展開および探索できます。これは、「デッド」テキストログよりも明らかに有利です。
これは、VS.NETデバッグウィンドウで最もよく使用するものです。
- コールスタック。これは、他の人のコードを把握するための優れた方法でもあります。
- 地元の人々と時計。
- イミディエイトウィンドウは、基本的にC＃コンソールであり、変数の内容の変更、初期化などを可能にします。
- 行をスキップし、次のステートメントを別の場所で実行するように設定する機能。
- 変数にカーソルを合わせて、値を表示するツールヒントを表示する機能。
要約すると、小さなウィンドウだけでなく、実行中のコードの状態を360度表示できます。
この種のことを教えている本は一度も見つかりませんでしたが、繰り返しになりますが、非常にシンプルで、WYSIWYGです。
印刷ステートメントを使用してマルチスレッドアプリケーションをデバッグすると、バナナが発生するためです。はい、まだprintステートメントでそれを行うことができますが、それらの多くが必要であり、マルチスレッド実行をエミュレートするためにステートメントのシーケンシャル印刷を解くには長い時間がかかります。
人間の脳は残念ながらシングルスレッドのみです。
Printfと比較したデバッガーの利点（IDEデバッガーではなくデバッガーであることに注意してください）
ウォッチポイントを設定できます。これは、メモリ破損を見つけるための私のお気に入りの方法の1つです
現時点では再コンパイルできないバイナリをデバッグできます
再コンパイルに時間がかかるバイナリをデバッグできます
その場で変数を変更できます
その場で関数を呼び出すことができます
デバッグステートメネットがフラッシュされないため、タイミングの問題を正確にデバッグできない問題はありません。
デバッガーはコアダンプを支援し、ステートメントを出力しない
本へのポインタを求めたので... Windowsのデバッグに関する限り、John RobbinsはWindowsのデバッグに関する優れた本のいくつかの版を持っています。
Microsoft .NETおよびMicrosoft Windows用のアプリケーションのデバッグ
最新版（ Debugging Microsoft .NET 2.0 Applications ）は.NETのみであるため、ネイティブコードのデバッグが必要な場合（最初のリンクのように）古いエディションが必要になる場合があります.NETおよびネイティブ）。
個人的には、答えは「統合されたデバッガー/ IDEにより、コマンドをパンチすることなく、さまざまな情報をすばやく提供できます。情報は、何をすべきかわからなくても、目の前にある傾向があります」見せて.
情報を取得できるeaseが、単なるコマンドラインデバッグまたは「printf」デバッグよりも優れている理由です。
他のポスターが言ったことの多くに加えて、コンピューターと一緒に一度に1行ずつステップスルーするのが本当に好きです。多くの場合、「次の行」ボタンをクリックすると、変数の値を見るように強制されているため、変数の値を見なくてもバグをキャッチします。ただし、ビルは、おそらくこのスキルを既に持っているので、私の答えがあなたに役立つとは思わない。
学習リソースに関する限り、使用したことはありません。すべてのメニューとオプションを調べています。
デバッグにはプリントとIDEの両方を使用しましたが、IDEを使用してデバッグする方がはるかに適切です。それがうまくいかない唯一の時間は、印刷ステートメントでコードを散らかし、ひどく間違ってしまった後にログファイルを見るというタイムクリティカルな状況（オンラインゲームのデバッグのような）です。それでも解決できない場合は、プリントを追加して繰り返します。
別のことは、新しい古いプロジェクトに参加し、コードがどのように実行されているかを誰も実際に知らない場合、変数/オブジェクト/ ...をエコーしてデバッグすることはできないということですまったく実行された。
私の仕事ではまさにそのような状況に直面しており、視覚的なXDebugingは、何がどこで何が起こっているのかを把握するのに役立ちます。
宜しくお願いします
ラファエル
IDEでのデバッグは、共有ホストなど、エラーログやシェルアクセスが利用できない環境では非常に役立ちます。その場合、IDEリモートデバッガーは、ビューstderrやstdoutなどの簡単な操作を実行できる唯一のツールです。
デバッガーは実行中のプロセスに接続できます
多くの場合、デバッガからスレッド化されたコードをデバッグするのが簡単です
誰かが上で言ったように：デバッガ！= IDE。
gdbと（当時の）TurboDebugger（スタンドアロン）は、サポートしている言語で問題なく動作します[ed]、ありがとう。 （またはさらに古いテクノロジー：xBase実行可能ファイル自体にリンクされたClipperデバッガー）-これらのどれもIDEを必要としませんでした
また、C/++コーディングはよりまれですが、printfステートメントは、見つけようとしているまさにそのバグを隠すことがあります！ （たとえば、スタック上の自動変数の初期化の問題、またはメモリの割り当て/アライメント）
最後に、他の人が述べたように、両方を使用できます。いくつかのリアルタイムのような問題は、ほとんど印刷、または少なくとも賢明な「* video_dbg =（is_good？ '+'： '-'）;」を必要とします。ビデオメモリのどこかに。私の年齢は示しています、これはDOSの下でした:-)
TMTOWTDI
既に述べた多くのことに加えて、printfに対するデバッガの最も重要な利点の1つは、printfステートメントを使用すると、バグが存在する機能を知っていることを前提とすることです。多くの場合、あなたはそうしないので、ローカライズするためにいくつかの推測を行い、printステートメントを他の多くの関数に追加する必要があります。バグは、フレームワークコードにあるか、またはあなたが考えている場所から遠く離れたところにある可能性があります。デバッガーでは、ブレークポイントを設定して、コードのさまざまな領域やさまざまな時点で状態を調べる方がはるかに簡単です。
また、適切なデバッガーでは、条件とアクションをブレークポイントに付加することにより、printfスタイルのデバッグを実行できるため、コードを変更することなくprintfデバッグの利点を保持できます。
ワウ、この質問が好きですか。決してあえてポーズをとらない...
人々は異なる働き方をしているようです。私にとって最適なのは：
- メモリ管理を含むコードの堅実なモデルを持つ
- 何が起こっているのかを追跡するためのインストルメンテーション（printステートメントなど）の使用。
私は40年以上にわたって生計を立てており、C++およびPython dailyの非自明な技術的および科学的アプリケーションで働いています。デバッガーが役に立たないという個人的な経験があります。ちょっと。
それがいいとは言いません。それが悪いとは言わない。共有したいだけです。
IDEのコンソールデバッガーvs printfおよびvsデバッガーの便利な機能について言及したかっただけです。
リモートアプリケーション（明らかにDEBUGモードでコンパイル）にアタッチし、POSIX teeユーティリティを使用してデバッガー出力をファイルにダンプする状態を検査できます。 printfと比較して、実行時に状態を出力する場所を選択できます。
アグレッシブな環境でデプロイされたAdobe Flashアプリケーションをデバッグしていたときに非常に役立ちました。必要なのは、各ブレークポイントで必要な状態を出力するアクションを定義し、fdb | tee output.logでコンソールデバッガーを起動し、いくつかのブレークポイントをウォークスルーするだけです。その後、ログを印刷し、さまざまなブレークポイントの状態を徹底的に比較することで情報を分析できます。
残念ながら、この機能[ファイルへのロギング]はGUIデバッガーではほとんど利用できないため、開発者は頭の中でオブジェクトの状態を比較できます。
ところで、私の意見では、デバッガを開始する前に、どこで何をデバッグするかを計画する必要があります。
Print文の使用に関する問題は、コードが混乱することです。 IEには、10の部分からなる関数があり、どこかでクラッシュすることはわかっていますが、どこにあるかわかりません。したがって、バグがどこにあるかを特定するために、10個の追加のprintステートメントを追加します。バグを見つけて解決したら、これらのprintステートメントをすべて削除してクリーンアップする必要があります。たぶんあなたはそうするでしょう。たぶん忘れてしまい、本番環境になってしまい、ユーザーのコンソールにはデバッグプリントがいっぱいになってしまいます。
IDEデバッガーを使用すると、実行を停止するたびに、現在のスコープ内のすべての変数の値（コールスタック全体）を確認できます。
印刷ステートメントは素晴らしい場合がありますが、任意の場所で画面に大量の情報をダンプすると、whole多くの印刷ステートメントが生成される可能性があります。
また、多くのIDEデバッガーを使用すると、メソッドを入力して評価し、停止中にメンバーを評価できます。これにより、必要な印刷ステートメントの量がさらに増加します。
ただし、一部の言語ではデバッガーが他の言語より優れていると感じています...
私の一般的な意見は、IDEデバッガーはJavaまたはC＃のようなマネージド言語にとって絶対に驚くほど素晴らしいです。C++ではかなり便利であり、 Pythonのようなスクリプト言語（ただし、スクリプト言語用の優れたデバッガーをまだ試したことがない可能性があります）。
私はIntelliJのデバッガが大好きですIDEA開発時Java開発。Pythonを使用するときはprintステートメントを使用します。
これは本当のプログラマーからの本当の質問でもありますか？
5分もprintステートメントでデバッグし、IDE-でさえデバッグせずにデバッグします！