IDEでのデバッグが優れているのはなぜですか？[閉まっている]

私は20年以上ソフトウェア開発者として、C、Perl、SQL、Java、PHP、JavaScript、そして最近ではPythonでプログラミングしています。私は、いくつかの注意深い思考と適切に配置されたデバッグprintステートメントを使用してデバッグできない問題に遭遇したことがありません。

私のテクニックは原始的であり、IDEで実際のデバッガを使用する方がはるかに優れていると多くの人が言うことを尊重します。それでも私の観察では、IDEユーザーは、私の石ナイフとクマの皮を使用して、私よりも速くまたはよりうまくデバッグしているようには見えません。私は適切なツールを学ぶことに心からオープンですが、ビジュアルデバッガーを使用することの説得力のある利点を示したことはありません。

さらに、ブレークポイントを設定して変数の内容を表示する方法の基本を超えて、IDEを使用して効果的にデバッグする方法を示すチュートリアルや本を読んだことがありません。

何が欠けていますか？IDEデバッグツールは、診断printステートメントを慎重に使用するよりもはるかに効果的です。

IDEデバッグのより優れた手法を示すリソース（チュートリアル、書籍、スクリーンキャスト）を提案できますか？

甘い答え！お時間を割いていただき、ありがとうございました。非常に明るい。私は多くに賛成票を投じ、どれにも反対票を投じなかった。

いくつかの注目すべき点：

• デバッガーは、変数、コード、またはランタイム環境の他の側面のアドホックインスペクションまたは変更を行うのに役立ちますが、手動デバッグでは、アプリケーションを停止、編集、および再実行する必要があります（おそらく再コンパイルが必要です）。
• デバッガーは実行中のプロセスにアタッチしたり、クラッシュダンプを使用したりできますが、手動デバッグでは、「再現するための手順」が必要です。
• デバッガーは、複雑なデータ構造、マルチスレッド環境、または完全なランタイムスタックを簡単かつ読みやすい方法で表示できます。
• デバッガーは、ほとんどすべてのデバッグタスクを実行する時間と反復作業を削減する多くの方法を提供します。
• ビジュアルデバッガーとコンソールデバッガーはどちらも便利で、多くの機能が共通しています。
• IDEに統合されたビジュアルデバッガーを使用すると、単一の統合開発環境（その名前）で、スマート編集やIDEの他のすべての機能に簡単にアクセスできます。

IDEデバッガーがコード内のトレースメッセージに対して提供するいくつかの機能の例：

• いつでもコールスタックを表示して、現在のスタックフレームのコンテキストを確認できます。
• トレースを追加する目的で再コンパイルできないライブラリにステップインします（デバッグシンボルにアクセスできる場合）。
• プログラムの実行中に変数値を変更する
• 編集して続行- コードの実行中にコードを変更し、変更の結果をすぐに確認する機能
• 変数を監視し、いつ変化するかを確認できる
• コードのセクションをスキップまたは繰り返して、コードのパフォーマンスを確認する。これにより、理論上の変更を行う前にテストすることができます。
• メモリの内容をリアルタイムで調べる
• 特定の例外がスローされた場合は、それらがアプリケーションによって処理されている場合でも、アラートを出します。
• 条件付きブレークポイント。例外的な状況でのみアプリケーションを停止して、スタックと変数を分析できるようにします。
• マルチスレッドアプリケーションでスレッドコンテキストを表示します。これは、トレースでは実現が難しい場合があります（異なるスレッドからのトレースが出力にインターリーブされるため）。

要約すると、印刷ステートメントは（通常）静的であり、元のステートメントが十分に詳細ではなかった場合は、追加の情報を取得するために再コンパイルする必要があります。IDEはこの静的な障壁を取り除き、あなたの指先で動的なツールキットを提供します。

私が最初にコーディングを始めたとき、私はデバッガーの大事なことを理解できず、トレースで何でも達成できると思っていました（もちろん、それはUNIX上で、デバッガーはGDBでした）。しかし、グラフィカルデバッガーを適切に使用する方法を習得したら、ステートメントの印刷に戻りたくありません。

• IDEデバッガーを使用すると、実行時に変数の値を変更できます。

• IDEデバッガーを使用すると、実行の開始時に確認したいと思っていた変数の値を確認できます。

• IDEデバッガーを使用すると、コールスタックを確認して、奇妙な値を渡された関数の状態を調べることができます。（この関数が何百もの場所から呼び出されていると考えてください、これらの奇妙な値がどこから来ているのかわかりません）

• IDEデバッガーを使用すると、行番号ではなく条件に基づいて、コードの任意の時点で条件付きで実行を中断できます。

• IDEデバッガーを使用すると、単に処理するのではなく、未処理の例外が発生した場合にプログラムの状態を調べることができます。

これは、「print」ステートメントでは絶対にデバッグできないものの1つです。これは、顧客がメモリダンプを持ち込んで「プログラムがクラッシュした、理由を教えてください」と言ったときです。

• コード全体でステートメントを印刷すると、読みやすさが低下します。
• デバッグ目的でのみそれらを追加および削除するには時間がかかります
• デバッガーはコールスタックを追跡し、現在の場所を簡単に確認できます
• 変数はその場で変更できます
• 実行の一時停止中にアドホックコマンドを実行して、診断を支援できます。
• 印刷ステートメントと組み合わせて使用​​できます：Debug.Write（ "..."）

printステートメントを使用したデバッグは失われた芸術であり、すべての開発者が学ぶことは非常に重要だと思います。その方法を知ったら、特定の種類のバグは、IDEを使用するよりもその方法でデバッグする方がはるかに簡単になります。この手法を知っているプログラマーは、デバッグ以外の目的でも、ログメッセージ（実際にはログを最後に読み取ることになることは言うまでもありません）に入力するのに役立つ情報をよく理解しています。

そうは言っても、異なるクラスのバグの方がはるかに簡単なので、ステップスルーデバッガーの使用方法を本当に知っている必要があります。その理由を説明するために、すでに投稿されている他の優れた回答に任せます:)

私の頭の上から：

1. 複雑なオブジェクトのデバッグ -デバッガーを使用すると、オブジェクトの内部に深く入り込むことができます。たとえば、オブジェクトに複雑なオブジェクトの配列の配列が含まれている場合、printステートメントでは、これまでのところしか取得できません。
2. 過去のコードをステップ実行する機能 -デバッガーを使用すると、実行したくない過去のコードをスキップすることもできます。確かに、これを手動で行うこともできますが、注入する必要があるコードはそれだけ多くなります。

IDEでデバッグする代わりに、次のこと を可能にするphpライブラリを備えた素晴らしいGoogle Chrome拡張PHPコンソールを試すことができます。

• Chrome JavaScriptコンソールと通知ポップアップでエラーと例外を確認します。
• 型変数をダンプします。
• PHPコードをリモートで実行します。
• パスワードでアクセスを保護します。
• リクエストごとにコンソールログをグループ化します。
• テキストエディタでerror file：lineにジャンプします。
• エラー/デバッグデータをクリップボードにコピーします（テスター用）。

私は20年近く開発していませんが、IDE /デバッガーを使用して次のことができることがわかりました。

• print文に含まれているとは思わなかったかもしれないあらゆる種類のことを見る
• コードをステップ実行して、コードが進むと思ったパスと一致するかどうかを確認します
• 変数を特定の値に設定して、コードに特定の分岐を行わせる

IDEを使用する理由の1つは、最新のIDEが単純なブレークポイント以上のものをサポートしていることです。たとえば、Visual Studioは次の高度なデバッグ機能を提供します。

• 条件付きブレークポイントを定義する（条件が満たされた場合にのみブレークするか、ブレークポイントのステートメントがn回実行されたときにのみブレークする）
• 未処理の例外で、または（特定の）例外がスローされるたびに中断する
• デバッグ中に変数を変更する
• 実行する次の行を設定してコードの一部を繰り返す
• 等

また、デバッガーを使用する場合、デバッグが終了したら、すべての印刷ステートメントを削除する必要はありません。

別の回答で見たことがないことに驚いたのは、2つのデバッグ方法が相互に排他的ではないということです。

printf標準のデバッガー（IDEベースかどうかに関係なく）を使用している場合でも、デバッグは非常にうまく機能します。特にロギングフレームワークを使用すると、リリースされた製品のすべてまたはほとんどをそのままにして、顧客の問題の診断に役立てることができます。

ここの他のほとんどすべての回答で述べたように、標準デバッガーの重要な優れた点は、プログラムの状態の詳細をより簡単に調査（および場合によっては変更）できることです。何を見たいかを前もって知る必要はありません-それはあなたの指先で（多かれ少なかれ）すべて利用可能です。

私の経験では、単純な印刷出力には、誰にも言及されていないように見える大きな利点が1つあります。

IDEデバッガーの問題は、すべてがリアルタイムで発生することです。プログラムを特定の時間に停止してから、ステップを1つずつ進めていきます。突然前に何が起こったかを確認したい場合は、戻ることはできません。これは、私たちの脳がどのように機能するかと矛盾しています。脳は情報を収集し、徐々に意見を形成します。その際、イベントを数回繰り返す必要があるかもしれませんが、いったん特定のポイントを通過すると、戻ることはできません。

これとは対照的に、選択された一連の出力/ログにより、「一時的なイベントの空間投影」が得られます。何が起こったかの完全なストーリーを提供し、上下にスクロールするだけで簡単に数回前と後ろに戻ることができます。「Bが発生する前にAが発生したのか」などの質問に簡単に回答できます。それはあなたが探しているにも関わらず、あなたがたはパターンを見るようにすることができる。

だから私の経験では。IDEとデバッガーは、単一のコールスタックの何かがうまくいかなかった場合の単純な問題を解決し、特定のクラッシュでのマシンの現在の状態を調査するための素晴らしいツールです。

ただし、段階的に状態が変化することが関係する、より困難な問題に取り組む場合。たとえば、あるアルゴリズムがデータ構造を破壊した場合、その結果、anohterアルゴリズムが失敗しました。あるいは、「これがどのくらいの頻度で発生するのか」、「私が想像するとおりに、順序どおりに発生するのか」などの質問に答えたい場合。そして、「古いファシニングされた」ロギング/プリントアウト技術には明らかな利点があります。

最善の方法は、いずれかの手法が最適な場合に使用することです。たとえば、ロギング/プリントアウトを使用していくつかのバグに移動し、ブレークポイントで一時停止して、現在の状態をさらに詳しく調べる必要があります。

ハイブリッドアプローチもあります。たとえば、console.log（object）を実行すると、ログにデータ構造ウィジェットが表示されます。このウィジェットは、展開してより詳細に調べることができます。これは、多くの場合、「デッド」テキストログよりも明らかに有利です。

印刷ステートメントを使用してマルチスレッドアプリケーションをデバッグすると、バナナが増えるからです。はい、それでも印刷ステートメントでそれを行うことができますが、それらの多くが必要であり、マルチスレッド実行をエミュレートするためにステートメントの順次印刷を解明するには長い時間がかかります。

残念ながら、人間の脳はシングルスレッドのみです。

本へのポインタを求めたので... Windowsデバッグに関する限り、John RobbinsはWindowsデバッグに関する優れた本のいくつかの版を持っています。

Microsoft .NETおよびMicrosoft Windowsのアプリケーションのデバッグ

最新のエディション（Microsoft .NET 2.0アプリケーションのデバッグ）は.NETのみであるため、ネイティブコードのデバッグ（.NETとネイティブの両方をカバー）が必要な場合は、最初のリンクのように古いバージョンが必要になる場合があります。

個人的には答えは「統合デバッガ/ IDEはコマンドをパンチする必要なしにさまざまな情報をすばやく提供します。情報は何をしているのかわからないまま、目の前にある傾向があります。見せて

簡単に情報を取得するためには、単にコマンドラインのデバッグ、または「printfの」デバッグより良いそれらを作るものです。

printfに対するデバッガーの利点（IDEデバッガーではなく、すべてのデバッガーに注意してください）

1. ウォッチポイントを設定できます。これは、メモリの破損を見つける私のお気に入りの方法の1つです。

2. 現在再コンパイルできないバイナリをデバッグできます

3. 再コンパイルに時間がかかるバイナリをデバッグできます

4. 変数をその場で変更できます

5. オンザフライで関数を呼び出すことができます

6. デバッグステートメットがフラッシュされないため、タイミングの問題を正確にデバッグできないという問題はありません。

7. デバッガーはコアダンプをサポートしますが、ステートメントを出力することはできません

これは、VS.NETデバッグウィンドウで最もよく使用するものです。

• コールスタックは、他の人のコードを理解するための優れた方法でもあります。
• ローカル＆時計。
• イミディエイトウィンドウ。基本的にはC＃コンソールであり、変数の内容を変更したり、初期化したりすることもできます。
• 行をスキップする機能。次のステートメントが別の場所で実行されるように設定します。
• 変数にカーソルを合わせて、その値を示すツールチップを表示する機能。

要約すると、小さなウィンドウではなく、実行中のコードの状態を360度表示できます。

この種のことを教える本を見つけたことはありませんが、繰り返しますが、それは非常に単純なようで、かなりWYSIWYGです。

• デバッガは実行中のプロセスに接続できます

• 多くの場合、デバッガーからスレッド化されたコードをデバッグする方が簡単です

IDEデバッガーを使用すると、実行を停止するたびに、現在のスコープ内のすべての変数の値を確認できます（コールスタック全体）。

print文は素晴らしいが、生成することができます任意の場所で画面にそれほど多くの情報をダンプすることができ、全体 print文の多くを。

また、多くのIDEデバッガーでは、メソッドを入力して評価し、停止中にメンバーを評価できます。これにより、実行する必要がある印刷ステートメントの量がさらに増加し​​ます。

デバッガは他の言語よりもいくつかの言語の方が優れていると思います...

IDEデバッガーは、JavaやC＃などのマネージ言語にとっては驚くほど素晴らしいものであり、C ++にとってはかなり有用であり、Pythonなどのスクリプト言語にとってはあまり有用ではないというのが私の一般的な意見です（ただし、私が試したことがなかっただけかもしれません）任意のスクリプト言語用のデバッガー）。

Java開発をするとき、私はIntelliJ IDEAのデバッガーが大好きです。Pythonを使用するときは、printステートメントだけを使用します。

誰かが上で言ったように：デバッガ！= IDE。

gdbと（昔の）TurboDebugger（スタンドアロン）は、サポートする言語で問題なく動作します。ありがとうございます。（またはさらに古いテクノロジー：xBase実行可能ファイル自体にリンクされたクリッパーデバッガー）-これらはどれもIDEを必要としませんでした

また、C / ++コーディングはよりまれですが、printfステートメントは、見つけようとしているまさにそのバグを隠すことがあります！（たとえば、スタック上の自動変数の初期化の問題、またはメモリの割り当て/配置）

最後に、他の人が述べたように、両方を使用できます。いくつかのリアルタイムっぽい問題は、ほとんど印刷、または少なくとも賢明な「* video_dbg =（is_good？ '+'： '-'）;」を必要とします。ビデオメモリのどこかに。私の年齢は示しています、これはDOSの下でした:-)

TMTOWTDI

他のポスターが言ったことの多くに加えて、私はコンピューターと一緒に一度に1行ずつステップ実行するのが本当に好きです。多くの場合、「次の行」ボタンをクリックしたときに変数の値を確認せざるを得ないので、変数の値を見ることさえせずにバグをキャッチします。しかし、私の答えはあなたに役立つとは思いません、ビル、おそらくあなたはすでにこのスキルを持っているでしょう。

学習リソースに関する限り、私は何も使用していません。すべてのメニューとオプションを調べているだけです。

これは本物のプログラマからの本当の質問ですか？

印刷ステートメントを使用したデバッグとIDEを使用したデバッグを5分も費やした人なら誰でも、質問することなくOCCURを実行できます。

デバッグにはプリントとIDEの両方を使用しており、IDEを使用してデバッグするほうがはるかに便利です。それがうまくいかないときの唯一の時間は、（オンラインゲームのデバッグのような）タイムクリティカルな状況で、コードを印刷ステートメントで散らかし、それがひどく間違った後にログファイルを見る場合です。それでもそれを理解できない場合は、さらにプリントを追加して繰り返します。

IDEのコンソールデバッガーvs printfおよびvsデバッガーの便利な機能について言及したかっただけです。

リモートアプリケーションに接続し（明らかにDEBUGモードでコンパイル）、POSIX teeユーティリティを使用してデバッガーの出力をファイルにダンプし、その状態を検査できます。printfと比較して、実行時に状態を出力する場所を選択できます。

アグレッシブな環境にデプロイされたAdobe Flashアプリケーションをデバッグしていたとき、それは多くの助けとなりました。各ブレークポイントで必要な状態を出力するアクションを定義し、でコンソールデバッガーを起動して、fdb | tee output.logいくつかのブレークポイントをウォークスルーするだけです。その後、ログを印刷し、さまざまなブレークポイントの状態を完全に比較することで情報を分析できます。

残念ながら、この機能[ファイルへのロギング]はGUIデバッガーではほとんど使用できないため、開発者は頭の中でオブジェクトの状態を比較できます。

ちなみに、私の見解では、デバッガを開始する前に、どこで何をデバッグするかを計画する必要があります。

さらに別のことは、新しい古いプロジェクトに参加し、コードがどのように実行されているかをだれも実際に知らない場合、変数/オブジェクト/ ...をエコーし​​てデバッグすることができないということです。まったく実行されました。

私の仕事では、まさにそのような状況に直面しており、視覚的なXDebuggingは、何がどこで何が起こっているかについてのアイデアを得るのに役立ちます。

宜しくお願いします

ラファエル

すでに述べた多くのことに加えて、printfよりもデバッガーの最も重要な利点の1つは、printfステートメントを使用すると、バグが存在する関数がわかっていることが前提となることです。多くの場合そうではないので、ローカライズするために、いくつかの推測を行い、他の多くの関数に印刷ステートメントを追加する必要があります。バグはフレームワークのコードにあるか、またはあなたが思っている場所から遠く離れた場所にある可能性があります。デバッガーでは、ブレークポイントを設定して、コードのさまざまな領域のさまざまな時点での状態を調べる方がはるかに簡単です。

また、適切なデバッガーを使用すると、ブレークポイントに条件とアクションをアタッチしてprintfスタイルのデバッグを実行できるため、printfデバッグの利点を維持できますが、コードを変更する必要はありません。

IDEでのデバッグは、共有ホストなど、エラーログやシェルアクセスが利用できない環境では非常に重要です。その場合、リモートデバッガーを備えたIDEが、view stderrやなどの簡単なことを実行できる唯一のツールですstdout。

printステートメントを使用する際の問題は、コードが混乱することです。IE、10個のパーツを持つ関数があり、どこかでクラッシュすることはわかっていますが、どこにいるかはわかりません。したがって、バグがどこにあるのかを特定するために、10の余分な印刷ステートメントを追加します。バグを見つけて解決したら、これらの印刷ステートメントをすべて削除してクリーンアップする必要があります。多分あなたはそれをするでしょう。多分あなたは忘れるでしょう、そしてそれは最終的に生産になり、そしてあなたのユーザーのコンソールはデバッグプリントでいっぱいになるでしょう。

ワウ、私はこの質問が好きですか。私はあえてそれをポーズすることはありませんでした...

人は働き方が違うようです。私にとって最も効果的なのは：

• メモリ管理を含む、私のコードのしっかりしたマインドモデルを持っている
• （printステートメントのような）インストルメンテーションを使用して、何が起こっているかを追跡します。

私は40年以上にわたって生涯のプログラミングを行っており、C ++とPythonの重要な技術的および科学的アプリケーションで日々働いており、デバッガーでは少しも役に立たないという個人的な経験があります。

それは良いとは言えません。それが悪いとは言わない。共有したいだけです。

デバッグだけではありません。IDEは、多くの方法でより良いソフトウェアをより速く構築するのに役立ちます。

• リファクタリングツール
• APIをより見つけやすくするため、またはおなじみのアイテムの正確なスペル/ケースを思い出させるためのインテリセンス（同じシステムを15年間使用している場合はあまり使用されませんが、それはまれです）
• 変数名とクラス名をオートコンプリートすることで、タイピングを節約
• コンパイルを開始する前に特定の種類のエラーを見つける
• 同じファイルまたはフォルダー内にない場合でも、変数/メソッド/クラス宣言/定義に自動的にジャンプします。
• 未処理および処理済みの例外を破る

私は続けることができました。