Почему отладка лучше в IDE? [закрыто]

Я более двадцати лет являюсь разработчиком программного обеспечения, программирую на 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», когда покупатель приносит вам дамп памяти и говорит «ваша программа потерпела крах, можете ли вы сказать мне, почему?»

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

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

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

С верхней части моей головы:

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

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

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

Я не занимался разработкой почти 20 лет, но обнаружил, что с помощью IDE / отладчика я могу:

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

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

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

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

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

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

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

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

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

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

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

Тем не менее, когда мы подходим к более сложным проблемам, где происходит постепенное изменение состояния. Например, один алгоритм повредил структуру данных, что, в свою очередь, привело к сбою другого алгоритма. Или, если мы хотим ответить на такие вопросы, как «как часто это происходит», «происходят ли вещи в том порядке и порядке, как я себе это представляю». и т. д. Тогда «старомодная» техника регистрации / распечатки имеет явное преимущество.

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

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

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

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

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

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

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

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

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

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

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

2. Может отладить двоичный файл, который вы не можете перекомпилировать в данный момент

3. Может отладить двоичный файл, который занимает много времени для перекомпиляции

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

5. Может вызывать функции на лету

6. Нет проблемы, когда отладочные состояния не сбрасываются, и, следовательно, проблема синхронизации не может быть отлажена точно

7. Отладчики помогают с дампами ядра, операторы печати не делают

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TMTOWTDI

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

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

Это настоящий вопрос от настоящего программиста?

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

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

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

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

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

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

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

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

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

С уважением

Раффаэль

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

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

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

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

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

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

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

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

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

Это не просто отладка. IDE помогает быстрее создавать лучшее программное обеспечение различными способами:

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

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