Почему отладка лучше в среде IDE?

Ответ 1

Некоторые примеры некоторых способностей, которые отладчик IDE даст вам сообщения о трассировке в коде:

• Просмотрите стек вызовов в любой момент времени, предоставив вам контекст для вашего текущего фрейма стека.
• Шаг в библиотеку, которую вы не можете перекомпилировать для целей добавления трасс (при условии, что у вас есть доступ к символам отладки)
• Изменить значения переменных во время работы программы
• Изменить и продолжить - возможность изменить код во время работы и сразу увидеть результаты изменения
• Можете смотреть переменные, видя, когда они меняют
• Уметь пропускать или повторять разделы кода, чтобы увидеть, как будет работать код. Это позволяет вам проверить теоретические изменения до их создания.
• Изучите содержимое памяти в режиме реального времени
• Оповестить вас, когда бросаются определенные исключения, даже если они обрабатываются приложением.
• Условная точка останова; останавливая приложение только в исключительных обстоятельствах, чтобы вы могли анализировать стек и переменные.
• Просмотрите контекст потока в многопоточных приложениях, чего может быть трудно достичь с помощью трассировки (поскольку в выходе будут чередоваться следы из разных потоков).

Таким образом, операторы печати (как правило) статичны, и вам нужно будет перекомпилировать, чтобы получить дополнительную информацию, если ваши исходные заявления недостаточно подробны. IDE удаляет этот статический барьер, предоставляя вам динамический инструментарий под рукой.

Когда я впервые начал кодирование, я не мог понять, что такое большая проблема с отладчиками, и я подумал, что могу добиться чего-то с трассировкой (предоставлено, это было в unix, а отладчиком был GDB). Но как только вы узнаете, как правильно использовать графический отладчик, вы не хотите возвращаться к операторам печати. ​​

Ответ 2

• Отладчик IDE позволяет вам изменять значения переменных во время выполнения.

• IDE отладчик позволяет увидеть значение переменные, которые вы не знали, что хотите чтобы увидеть, когда началось исполнение.

• IDE отладчик позволяет увидеть стек вызовов и изучить состояние функция передала странные значения. (думаю, эта функция вызывается из сотни мест, вы не знаете где происходят эти странные ценности от)

• Отладчик IDE позволяет вам условно разорвать исполнение на любом точка в коде, основанная на условии, а не номер строки.

• Отладчик IDE позволит вам проверить состояние программы в случае необработанного исключения, а не просто обрезать.

Ответ 3

Здесь одна вещь, которую вы определенно не можете отлаживать с помощью инструкции "print", когда клиент приносит вам дамп памяти и говорит: "Ваша программа разбилась, можете ли вы сказать мне, почему?"

Ответ 4

• Заявления на печать через весь код уменьшают читаемость.
• Добавление и удаление их для целей отладки занимает много времени
• Отладчики отслеживают стек вызовов, что позволяет легко видеть, где вы находитесь.
• Переменные могут быть изменены на лету
• Команды Adhoc могут выполняться во время паузы в выполнении, чтобы помочь диагностировать
• Может использоваться в CONJUNCTION с помощью операторов печати: Debug.Write( "..." )

Ответ 5

Я думаю, что отладка с использованием заявлений печати - это потерянное искусство, и очень важно, чтобы каждый разработчик учился. Как только вы знаете, как это сделать, некоторые классы ошибок становятся намного проще отлаживать, чем через IDE. Программисты, которые знают эту технику, также отлично понимают, какую полезную информацию можно разместить в сообщении журнала (не говоря уже о том, что вы действительно закончите чтение журнала) для целей не отладки.

Тем не менее, вы действительно должны знать, как использовать пошаговый отладчик, поскольку для другого класса ошибок это проще. Я оставлю это до других отличных ответов, уже отправленных, чтобы объяснить, почему:)

Ответ 6

Сверху моей головы:

• Отладка сложных объектов. Отладчики позволяют глубже проникнуть внутрь объекта. Если ваш объект имеет, скажем, массив массивов сложных объектов, операторы печати будут получать вас до сих пор.
• Возможность перехода по коду. Отладчики также позволят вам пропустить предыдущий код, который вы не хотите выполнять. Правда, вы могли бы сделать это вручную, но это гораздо больше кода, который вы должны ввести.

Ответ 7

В качестве альтернативы отладке в среде IDE вы можете попробовать отличное расширение Google Chrome Консоль PHP с php library, которая позволяет:

• См. ошибки и исключения в консоли Chrome JavaScript и всплывающих окнах уведомлений.
• Дамп любой переменной типа.
• Удаленное выполнение кода PHP.
• Защита доступа по паролю.
• Журналы групповой консоли по запросу.
• Перейти к файлу ошибки: строка в текстовом редакторе.
• Копировать ошибки/отладочные данные в буфер обмена (для тестеров).

Ответ 8

Я не развиваюсь почти 20 лет, но я считаю, что с помощью IDE/debugger я могу:

• см. всевозможные вещи, которые я, возможно, не считал включенными в оператор печати
• пройдите по коду, чтобы узнать, соответствует ли он пути, который, как я думал, потребуется
• задавать переменные для определенных значений, чтобы код выполнял определенные ветки

Ответ 9

Одной из причин использования IDE может быть то, что современные IDE поддерживают больше, чем простые точки останова. Например, Visual Studio предлагает следующие расширенные функции отладки:

• определить условные точки останова (ломаться только при выполнении условия или только в n-й раз, когда выполняется оператор в точке останова)
• прерывать необработанное исключение или всякий раз, когда нужно (конкретное) исключение
• изменить переменную во время отладки
• повторение фрагмента кода путем установки следующей строки, которая будет выполнена
• и др.

Кроме того, при использовании отладчика вам не придется удалять все ваши операторы печати после завершения отладки.

Ответ 10

Одна вещь, которую я удивляюсь, я не видел в другом ответе, что два метода отладки не являются взаимоисключающими.

printf Отладка может работать довольно хорошо, даже если вы используете стандартный отладчик (независимо от того, основана ли IDE или нет). В частности, с картой регистрации, поэтому вы можете оставить все или большую часть выпущенного продукта, чтобы помочь в диагностике проблем с клиентами.

Как уже упоминалось в большинстве других ответов, ключевая приятная вещь в стандартном отладчике заключается в том, что она позволяет вам более легко изучить (и потенциально изменить) детали состояния программы. Вам не обязательно знать, на что вы, возможно, захотите взглянуть - все это доступно у вас под рукой (более или менее).

Ответ 11

По моему опыту, простые распечатки имеют одно огромное преимущество, о котором никто не упоминает.

Проблема с отладчиком IDE заключается в том, что все происходит в реальном времени. Вы останавливаете программу в определенное время, затем вы делаете шаги по одному за раз, и невозможно вернуться назад, если вы вдруг захотите узнать, что произошло раньше. Это совершенно не согласуется с тем, как работает наш мозг. Мозг собирает информацию и постепенно формирует оппортунизм. Возможно, потребуется несколько раз повторять события, но как только вы перешли через определенный момент, вы не сможете вернуться назад.

В отличие от этого, выбранная серия распечаток/протоколирования дает вам "пространственную проекцию временных событий". Это дает вам полную информацию о том, что произошло, и вы можете вернуться назад и четверть несколько раз очень просто, просто прокручивая вверх и вниз. Это позволяет легко ответить на такие вопросы, как "произошло ли А до того, как Б". Это может заставить вас увидеть шаблоны, которые вы даже искали.

Итак, по моему опыту. IDE и отладчики - это фантастические инструменты для решения простых задач, когда что-то в одном стеке вызовов ошибочно и изучает текущее состояние машины при определенном сбое.

Однако, когда мы приближаемся к более сложным проблемам, в которых участвует постепенное изменение состояния. Где, например, один алгоритм исказил структуру данных, что, в свою очередь, вызвало отказ алгоритма анотер. Или, если мы хотим ответить на такие вопросы, как "как часто это происходит", "делать что-то в порядке и в том, как я себе представляю, что это произойдет". и т.д. Тогда "старая сфабрикованная" техника регистрации/распечатки имеет явное преимущество.

Лучше всего использовать любой метод, когда он наиболее подходит, например, использовать протоколирование/распечатки, чтобы получить некоторые ошибки, и сделать паузу в точке останова, где нам нужно более подробно изучить текущее состояние.

Существуют также гибридные подходы. Например, когда вы выполняете console.log(объект), вы получаете виджет структуры данных в журнале, который вы можете расширить и изучить более подробно. Это многократно дает явное преимущество перед "мертвым" текстовым журналом.

Ответ 12

Это то, что я больше всего использую в отладочных окнах VS.NET:

• Стек вызовов, который также является отличным способом выяснить код другого пользователя.
• Местные жители и часы.
• Немедленное окно, которое в основном представляет собой консоль С#, а также позволяет изменять содержимое переменной, инициализировать материал и т.д.
• Возможность пропустить строку, установить следующий оператор, который будет выполняться где-то еще.
• Возможность навести курсор на переменные и дать подсказку, показывающую мне их значения.

В общем, это дает мне 360-градусный обзор состояния моего исполняемого кода, а не только маленькое окно.

Никогда не находил книгу, преподавающую подобные вещи, но опять же, это кажется довольно простым, это в значительной степени WYSIWYG.

Ответ 13

Поскольку отладка многопоточных приложений с помощью операторов печати приведет вас к бананам. Да, вы все равно можете делать это с помощью операторов печати, но вам нужно много их и разгадать последовательную распечатку инструкций, чтобы эмулировать многопоточное исполнение, потребовалось бы много времени.

К сожалению, человеческий мозг только однопоточный.

Ответ 14

Преимущества отладчика над printf (отметить не отладчик IDE, а любой отладчик)

• Можно установить точки наблюдения. Это один из моих любимых способов поиска повреждений памяти.

• Может отлаживать двоичный файл, который вы не можете перекомпилировать в настоящий момент

• Может отлаживать двоичный файл, который занимает много времени, чтобы перекомпилировать

• Может менять переменные на лету

• Позволяет выполнять функции на лету

• Не имеет проблемы, когда отладка statemenets не сбрасывается, и поэтому проблема синхронизации не может быть отлажена acuratly

• Отладчики помогают с дампами ядра, печатают инструкции dont '

Ответ 15

Поскольку вы просили указатели на книги... Что касается отладки Windows, у Джона Роббинса есть несколько выпусков хорошей книги по отладке Windows:

Отладка приложений для Microsoft.NET и Microsoft Windows

Обратите внимание, что последнее издание (Отладка приложений Microsoft.NET 2.0) - это только .NET, поэтому вам может понадобиться более старая версия ( как в первой ссылке), если вы хотите отлаживать собственный код (он охватывает как .NET, так и native).

Ответ 16

Я лично считаю, что ответ так же прост, как "Интегрированный отладчик /IDE дает вам массу различной информации быстро, без необходимости штамповки в командах. Информация, как правило, находится перед вами, если вы не скажете это то, что вам показать.

Легкость, с которой может быть получена информация, делает их лучше, чем просто отладка командной строки или отладка "printf".

Ответ 17

• Отладчик может подключиться к выполняемому процессу

• Часто проще отлаживать потоковый код от отладчика

Ответ 18

С помощью отладчика IDE вы можете видеть значения ВСЕХ переменных в текущей области (вплоть до стека вызовов) всякий раз, когда вы останавливаете выполнение.

Операции с печатью могут быть большими, но сбрасывать так много информации на экран в любом месте может привести к большому количеству заявлений печати. ​​

Кроме того, многие отладчики IDE позволяют вводить и оценивать методы и оценивать участников во время их остановки, что еще больше увеличивает количество заявлений печати, которые вам нужно будет сделать.

Я чувствую, что отладчики лучше подходят для некоторых языков, чем для других, но...

Мое общее мнение заключается в том, что отладчики IDE абсолютно, удивительно замечательны для управляемых языков, таких как Java или С#, довольно полезны для С++ и не очень полезны для языков сценариев, таких как Python (но может быть, попробовал хороший отладчик для любых языков сценариев).

Мне очень нравится отладчик в IntelliJ IDEA, когда я занимаюсь разработкой Java. Я просто использую инструкции печати, когда я использую Python.

Ответ 19

Как сказал кто-то выше: Debugger!= IDE.

gdb и (назад в день) TurboDebugger (автономный) отлично подходит для языков, которые они поддерживают [ed], спасибо. (или еще более старая технология: отладчик Clipper, связанный с исполняемым файлом xBase) - ни одна из них не требовала IDE

Кроме того, хотя кодирование C/++ встречается реже, заявления printf иногда маскируют ту самую ошибку, которую вы пытаетесь найти! (например, проблемы инициализации в автоматическом vars в стеке или распределение/выравнивание памяти)

Наконец, как утверждают другие, вы можете использовать оба. Некоторые проблемы в реальном времени почти требуют печати или, по крайней мере, разумного "* video_dbg = (is_good? '+': '-'); где-то в видеопамяти. Мой возраст показывает, это было под DOS: -)

TMTOWTDI

Ответ 20

В дополнение к тому, что говорили другие плакаты, мне очень нравится переходить через одну линию одновременно с компьютером, поскольку это заставляет меня думать об одной строке за раз. Часто я поймаю ошибку, даже не рассматривая переменные значения просто потому, что я вынужден смотреть на нее, когда я нажимаю кнопку "следующая строка". Однако, я не думаю, что мой ответ поможет вам, Билл, потому что у вас, вероятно, уже есть этот навык.

Что касается учебных ресурсов, я не использовал их - я просто изучаю все меню и варианты.

Ответ 21

Это даже реальный вопрос от реального программиста?

Любой, кто потратил даже 5 минут на отладку с заявлениями печати и отладкой с помощью IDE, - он будет отвечать ему/ей, даже не спрашивая!

Ответ 22

Я использовал как отпечатки, так и IDE для отладки, и я бы скорее отлаживал использование среды IDE. Единственное время для меня, когда это не работает, - это критические ситуации во времени (например, отладка онлайн-игр), где вы замаскируете код инструкциями печати, а затем смотрите на файлы журнала после того, как он ужасно ошибочно. Тогда, если вы все еще не можете понять это, добавьте больше отпечатков и повторите.

Ответ 23

Просто хотел упомянуть полезную функцию консольного отладчика vs printf и vs отладчика в среде IDE.

Вы можете подключиться к удаленному приложению (obvioustly, скомпилированному в режиме DEBUG) и проверить его состояние, выгружая вывод отладчика в файл с помощью утилиты POSIX tee. По сравнению с printf вы можете выбрать, куда выводить состояние во время выполнения.

Это очень помогло мне, когда я отлаживал приложения Adobe Flash, развернутые в агрессивной среде. Вам просто нужно определить некоторые действия, которые печатают требуемое состояние в каждой точке останова, запустить консольный отладчик с помощью fdb | tee output.log и пройти через некоторые точки останова. После этого вы можете распечатать журнал и проанализировать информацию путем тщательного сравнения состояния в разных точках останова.

К сожалению, эта функция [запись в файл] редко доступна в отладчиках GUI, что позволяет разработчикам сравнивать состояние объектов в голове.

Кстати, я считаю, что нужно планировать, где и что отлаживать, прежде чем смотреть отладчика.

Ответ 24

Ну, еще одна вещь: если вы присоединитесь к новому старому проекту, и никто не знает, как код делает то, что он делает, тогда вы не можете отлаживать, повторяя переменные/объекты/... b/c, вы не знаете какой код выполняется вообще.

На моей работе я столкнулся именно с такой ситуацией и визуальным XDebuging помогает мне получить представление о том, что происходит и где вообще.

С наилучшими пожеланиями

Раффаэль

Ответ 25

Отладка в среде IDE неоценима в среде, где журналы ошибок и доступ к оболочке недоступны, например, общий хост. В этом случае IDE с удаленным отладчиком является единственным инструментом, который позволяет выполнять простые вещи, такие как view stderr или stdout.

Ответ 26

Помимо многих вещей, о которых уже упоминалось, одним из наиболее важных преимуществ отладчика над printf является то, что использование операторов printf предполагает, что вы знаете, в какой функции находится ошибка. Во многих случаях вы этого не делаете, поэтому вам нужно сделать несколько догадок и добавить инструкции печати ко многим другим функциям, чтобы локализовать их. Ошибка может быть в коде кода или где-то далеко от того, где вы думаете. В отладчике гораздо проще установить точки останова для проверки состояния в разных областях кода и в разные моменты времени.

Кроме того, достойный отладчик позволит вам отлаживать отпечаток в стиле printf, добавляя условия и действия к точкам останова, чтобы вы по-прежнему сохраняли преимущества отладки printf, но не изменяя код.

Ответ 27

Проблема с использованием операторов печати - это беспорядок вашего кода. IE, у вас есть функция с 10 частями, и вы знаете, что она сбой где-то, но вы не знаете, где. Таким образом, вы добавляете в 10 дополнительных операторов печати, чтобы определить, где ошибка. После того как вы нашли и решили свою ошибку, теперь вам нужно очистить, удалив все эти инструкции печати. Может быть, вы это сделаете. Возможно, вы забудете, и это закончится производством, и ваша консоль пользователя будет заполнена отладочными отпечатками.

Ответ 28

Вау, мне нравится этот вопрос. Я никогда не осмеливался это позировать...

Кажется, что у людей просто разные способы работы. Для меня лучше всего работает:

• Наличие модели интеллектуального ума моего кода, включая управление памятью
• Используя инструментарий (например, заявления печати), чтобы следить за тем, что происходит.

Я уже более 40 лет зарабатывал себе на жизнь программированием, работая в нетривиальных технических и научных приложениях на С++ и Python ежедневно, и у меня есть личный опыт, который отладчик мне немного не помогает.

Я не говорю, что это хорошо. Я не говорю, что это плохо. Я просто хочу поделиться им.

Ответ 29

Это не просто отладка. IDE помогает вам быстрее создавать более быстрое ПО:

• инструменты рефакторинга
• intellisense, чтобы сделать api более узнаваемым или напоминать точную орфографическую/случайную информацию о знакомых предметах (не очень полезно, если вы использовали ту же систему в течение 15 лет, но это редко)
• сохранить при вводе с помощью автозаполнения переменных и имен классов
• найдите определенные типы ошибок, прежде чем вы начнете компилировать
• Автоматически переходить в объявления/определения переменных/методов/классов, даже если они не находятся в одном файле или папке.
• Перерыв на необработанных и обработанных исключениях

Я мог бы продолжить.