как искать ошибки в коде используете ли вы дебаггер
Пять инструментов отладки JavaScript, о которых полезно знать
Вы смотрите на код и не можете понять — почему! Почему он делает нечто неожиданное, и в общем-то, если не близится дедлайн, интересное. Однако от всех этих неожиданностей, в любом случае, надо избавляться.
Прежде чем вы, бросив всё остальное, кинетесь складывать в кучу найденные где-то строчки программ, которые, вроде бы, способны решить вашу задачу, ответьте пожалуйста на три вопроса:
Проверка значений переменных
Работа в браузере: с осторожностью относитесь к выведенным данным, после которых находится светло-синий значок с белой буквой «i». Возможно, эти данные были обновлены после выполнения программы
№1: инструменты разработчика Chrome — отладчик
Более надёжной альтернативой использования console.log() является отладчик Chrome. Для того, чтобы им воспользоваться, добавьте команду debugger в ту строку вашего кода, в которой вам хотелось бы исследовать значения переменных. Сохраните файл, затем откройте панель инструментов разработчика Chrome, например, следующими командами:
Перейдите к странице, код которой исследуете, скажем, это может быть что-то вроде localhost:PORT_NUMBER или адрес страницы на разрабатываемом сайте, либо, если страница уже открыта, перезагрузите её. Исполнение приостановится на команде debugger и вы сможете исследовать программу.
Работа в браузере: исполнение приостановится на команде debugger и вы сможете исследовать программу
Использование команды debugger аналогично добавлению точки останова из панели Sources в браузере, но основное отличие, на которое стоит обратить внимание, заключается в том, что точки останова привязаны к номерам строк. Предположим, вы поставили точку останова на строке 20, а затем переработали код и удалили строку 8. То, что было в строке 20, теперь окажется в строке 19 и вам придётся переставить на новое место точку останова. Подробности об отладке в Chrome и разные полезные сведения об этом процессе можно узнать, обратившись к документации.
Обратите внимание на то, что похожие средства отладки имеются в браузерах Firefox, Safari и Edge.
Инструменты разработчика Chrome — вкладка Network
Если вы не знаете точно, выполнен ли запрос к серверу, перейдите к вкладке Network инструментов разработчика Chrome. Посмотрите на список вызовов для запроса, в котором вы не уверены. Вы можете проверить код состояния запроса, просмотреть заголовки запроса и другие сведения о нём.
Работа в браузере: вкладка Network инструментов разработчика Chrome показывает запросы к серверу. Щелчок по строке запроса позволяет просмотреть заголовки и другие сведения
№2: React Developer Tools
Если ваше приложение основано на React и нужно проверить значения свойств или состояний, вам стоит познакомиться с расширением React Developer Tools для Chrome. Оно немедленно станет вашим лучшим другом.
Добавив в Chrome это расширение и перейдя на страницу, созданную с помощью React, вы увидите в консоли разработчика вкладку React, которая выводит значения свойств и состояния для элемента, по которому вы щёлкнете.
Работа в браузере: вкладка React показывает значения свойств и состояния если они существуют для выбранного элемента
№3: отладка серверного кода и Node Inspect
Итак, вы уверены в том, что программа работает, что данные уходят на сервер, но не знаете, правильно ли Node или Express маршрутизируют и обрабатывают запрос. Если вы используете приложение, в исходный код которого взглянуть не можете, например, это некое API стороннего сервиса, тогда почитайте документацию. Если же вы сами разрабатываете и поддерживаете сервер, тогда вам стоит познакомиться с Node Inspect.
Node Inspect похож на инструменты разработчика Chrome, но предназначен он для серверного кода. Прежде чем пользоваться этим средством, проверьте версию Node, она должна быть не ниже 6.6, и версию Chrome, которая должна быть не ниже 55. Если эти требования выполнены, откройте командную строку и выполните команду следующего вида:
После этого вы должны увидеть сообщение, в котором нам наиболее интересна ссылка.
Отладка серверного кода: включение отладчика Node
Эту ссылку надо открыть в браузере, после чего можно будет воспользоваться знакомыми инструментами для отладки серверного кода.
Если вы стремитесь быть на переднем крае прогресса в области отладки, взгляните на этот материал, где рассмотрена настройка окружения для одновременной отладки клиентских и серверных JavaScript-программ в одном и том же окне инструментов разработчика Chrome.
№4: проверка ответа сервера — Postman
Если вы уверены в том, что запрос отправлен на сервер, но вы не знаете точно, как выглядит то, что пришло в ответ, или даже в том, пришло ли что-нибудь вообще, разобраться в ситуации вам поможет Postman. Хотя этот товарищ и не супермен из комиксов, нескольких разработчиков он точно спас.
Postman — это настольное приложение, его надо скачать и установить. Оно позволяет выбрать вид запроса (среди них — GET, POST, PUT, PATCH, DELETE), добавить нужную вам конечную точку, а если надо — то и данные для аутентификации, и отправить запрос на сервер. Ответ сервера появится в приложении на вкладке Body.
Работа в Postman: выберите вид запроса, введите сведения о конечной точке, данные для аутентификации, и нажмите кнопку Send. Ответ сервера появится на вкладке Body
Этот инструмент очень удобен в случаях, когда нужно удостовериться в том, что с сервера приходит именно то, чего вы от него ожидаете, то есть, убедиться в том, что функция на клиенте, которая обрабатывает ответы сервера, сможет разобраться с полученными данными. Подробности о работе с Postman можно найти в его документации.
№5: синтаксические ошибки и Webpack
В борьбе с синтаксическими ошибками весьма полезен линтер, подключённый к текстовому редактору, например, ESLint. Сообщения об ошибках в консоли браузера или в командной строке также обычно помогают понять, на что стоит обратить внимание и какую строку стоит искать в тексте для исправления синтаксической ошибки. Ещё одно полезное средство проверки синтаксиса, хотя и менее известное в таком качестве — это Webpack. Да — это тот же самый Webpack, который используют для компиляции модулей.
Если Webpack не может собрать модуль, он выдаст сообщение об ошибке, из которого можно узнать много полезного. Поэтому, если вы обновляете страницу, а в браузере ничего нового не появляется, взгляните на то, что Webpack выводит в терминале и проверьте, может ли он скомпилировать то, с чем вы пытаетесь работать.
Работа с Webpack: Если Webpack не может скомпилировать код, он выдаст ошибку и сведения о том, где именно, с точностью до символа в строке, она произошла.
Итоги: что делать, если ошибка не исчезает
Если вам, несмотря ни на что, не удаётся справиться с ошибкой, подготовьте краткий и точный вопрос, задайте его руководителю, сослуживцу, или попросите совета на каком-нибудь подходящем форуме. Вашу проблему наверняка удастся решить.
Уважаемые читатели! Как вы ищете ошибки в JavaScript-коде?
Как искать и исправлять ошибки в коде
Вы читаете свежую версию статьи. Мы обновили и дополнили материал, изначально опубликованный 1 июля 2015 года.
Искать ошибки в программах — непростая задача. Здесь нет никаких готовых методик или рецептов успеха. Можно даже сказать, что это — искусство. Тем не менее есть общие советы, которые помогут вам при поиске. В статье описаны основные шаги, которые стоит предпринять, если ваша программа работает некорректно.
Шаг 1: Занесите ошибку в трекер
После выполнения всех описанных ниже шагов может так случиться, что вы будете рвать на себе волосы от безысходности, все еще сидя на работе, когда поймете, что:
Трекер поможет вам не потерять нить размышлений и о текущей проблеме, и о той, которую вы временно отложили. А если вы работаете в команде, это поможет делегировать исправление коллеге и держать все обсуждение в одном месте.
Вы должны записать в трекер следующую информацию:
Это должно подсказать, как воспроизвести ошибку. Если вы не сможете воспроизвести ее в любое время, ваши шансы исправить ошибку стремятся к нулю.
Шаг 2: Поищите сообщение об ошибке в сети
Если у вас есть сообщение об ошибке, то вам повезло. Или оно будет достаточно информативным, чтобы вы поняли, где и в чем заключается ошибка, или у вас будет готовый запрос для поиска в сети. Не повезло? Тогда переходите к следующему шагу.
Шаг 3: Найдите строку, в которой проявляется ошибка
Если ошибка вызывает падение программы, попробуйте запустить её в IDE под отладчиком и посмотрите, на какой строчке кода она остановится. Совершенно необязательно, что ошибка будет именно в этой строке (см. следующий шаг), но, по крайней мере, это может дать вам информацию о природе бага.
Шаг 4: Найдите точную строку, в которой появилась ошибка
Как только вы найдете строку, в которой проявляется ошибка, вы можете пройти назад по коду, чтобы найти, где она содержится. Иногда это может быть одна и та же строка. Но чаще всего вы обнаружите, что строка, на которой упала программа, ни при чем, а причина ошибки — в неправильных данных, которые появились ранее.
Если вы отслеживаете выполнение программы в отладчике, то вы можете пройтись назад по стектрейсу, чтобы найти ошибку. Если вы находитесь внутри функции, вызванной внутри другой функции, вызванной внутри другой функции, то стектрейс покажет список функций до самой точки входа в программу (функции main() ). Если ошибка случилась где-то в подключаемой библиотеке, предположите, что ошибка все-таки в вашей программе — это случается гораздо чаще. Найдите по стектрейсу, откуда в вашем коде вызывается библиотечная функция, и продолжайте искать.
Шаг 5: Выясните природу ошибки
Ошибки могут проявлять себя по-разному, но большинство из них можно отнести к той или иной категории. Вот наиболее частые.
Если ваша ошибка не похожа на описанные выше, или вы не можете найти строку, в которой она появилась, переходите к следующему шагу.
Шаг 6: Метод исключения
Если вы не можете найти строку с ошибкой, попробуйте или отключать (комментировать) блоки кода до тех пор, пока ошибка не пропадет, или, используя фреймворк для юнит-тестов, изолируйте отдельные методы и вызывайте их с теми же параметрами, что и в реальном коде.
Попробуйте отключать компоненты системы один за другим, пока не найдете минимальную конфигурацию, которая будет работать. Затем подключайте их обратно по одному, пока ошибка не вернется. Таким образом вы вернетесь на шаг 3.
Шаг 7: Логгируйте все подряд и анализируйте журнал
Пройдитесь по каждому модулю или компоненту и добавьте больше сообщений. Начинайте постепенно, по одному модулю. Анализируйте лог до тех пор, пока не проявится неисправность. Если этого не случилось, добавьте еще сообщений.
Ваша задача состоит в том, чтобы вернуться к шагу 3, обнаружив, где проявляется ошибка. Также это именно тот случай, когда стоит использовать сторонние библиотеки для более тщательного логгирования.
Шаг 8: Исключите влияние железа или платформы
Замените оперативную память, жесткие диски, поменяйте сервер или рабочую станцию. Установите обновления, удалите обновления. Если ошибка пропадет, то причиной было железо, ОС или среда. Вы можете по желанию попробовать этот шаг раньше, так как неполадки в железе часто маскируют ошибки в ПО.
Если ваша программа работает по сети, проверьте свитч, замените кабель или запустите программу в другой сети.
Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?
Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.
Шаг 9: Обратите внимание на совпадения
Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).
Шаг 10: Обратитесь в техподдержку
Наконец, пора попросить помощи у того, кто знает больше, чем вы. Для этого у вас должно быть хотя бы примерное понимание того, где находится ошибка — в железе, базе данных, компиляторе. Прежде чем писать письмо разработчикам, попробуйте задать вопрос на профильном форуме.
Ошибки есть в операционных системах, компиляторах, фреймворках и библиотеках, и ваша программа может быть действительно корректна. Но шансы привлечь внимание разработчика к этим ошибкам невелики, если вы не сможете предоставить подробный алгоритм их воспроизведения. Дружелюбный разработчик может помочь вам в этом, но чаще всего, если проблему сложно воспроизвести вас просто проигнорируют. К сожалению, это значит, что нужно приложить больше усилий при составлении багрепорта.
Полезные советы (когда ничего не помогает)
Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
2. Внимательно просмотрите код.
Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
4. Идите спать.
Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
5. Сделайте творческий перерыв.
Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
6. Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
7. Поиграйте в доктора Хауса (только без Викодина).
Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?
Что вам точно не поможет
Ошибка, которую я недавно исправил
Отладка Javascript
(Примечание: наверное эта статья больше для новичков. Так что не судите строго)
Казалось бы — да что тут рассказывать? Всё же очевидно. Но вопрос этот мне задают с завидной частотой. Да и мне есть, что рассказать.
Приведу конкретные примеры и расскажу, как я их решаю.
Видим цель, не видим препятствий
JavaScript вывалил ошибку? Замечательно! Нет, это конечно плохо, но гораздо лучше, чем если бы он промолчал (да, бывает и такое!) в случае ошибки.
Наша цель — понять, что же, чёрт побери, произошло? Но сначала — рекламная пауза лирическое отступление: средства JavaScript Debug’а в основных браузерах.
Debuggers
Как «тормознуть» поток
А вот вариант с условной остановкой:
Мне так нравится гораздо больше, чем ставить «бряку»: так я пишу код и дебажу его по сути в одном месте, а не в двух.
Debug через alert()
Это наименее информативный debug, который к тому же останавливает поток JavaScript. Да к тому же модальный по отношению к браузеру. Забудьте, что он вообще существует.
Особенность breakpoint’ов
Рассмотренные варианты все, как один, тормозят поток JavaScript. Это плохо!
Почему? Если в момент остановки скрипта у вас был запущен AJAX-запрос или Timeout, и ответ не успел вернутся — он может уже не вернутся никогда. Согласитесь, в современных web-проектах этого добра хватает. Поэтому в момент «экстренной остановки» скрипта мы уже не сможем адекватно debug’ать дальше — часть логики будет безвозвратно утеряна.
Поэтому я стараюсь избегать на практике debug с остановкой.
«Debugging JavaScript with breakpoints is bad, mmkay?» © Mr. Mackey, South Park
Однако: breakpoint есть breakpoint, и если вы исследуете ну очень запущенный баг — тут без остановки не обойтись (надо будет сделать watch текущим переменным и т.д.)
«Правильный» debug
Пример №1
JavaScript показал ошибку. Надо понять — что к чему.
Включаем в debugger’е режим «Break On Error»:
Воспроизводим ошибку снова. JavaScript останавливается. Видим место ошибки, делаем watch и точно определяем, в чём же дело.
Пример №2
CASE:
JavaScript не показал ошибку. Но вы знаете, что она есть (как суслик). Да, такое иногда бывает.
CASE:
Надо просто продебажить некий код. Скажем, посмотреть, что происходит по нажатию кнопки или после AJAX-загрузки данных.
Тут сложней — надо найти, с чего начать.
Немного искусства
// условная остановка
if (allowBreakpoints == true )
debugger;
Конечно данный способ не идеален. Бывает, что даёт промашки. Но это хороший способ, мне он сильно помагает в работе.
Так, значит место в коде нашли, бряку поставили. Если не хочется (или просто нельзя) изменять исходный код — можно вместо ключевого слова debugger поставить brakepoint в средстве отладки.
Пример №3
Тот же случай: надо продебажить некий код. Скажем, посмотреть, что происходит по нажатию кнопки или после AJAX-загрузки данных. Но в этот раз мы не можем тормозить поток JavaScript по описанным мной причинам.
CASE UNO
variable_to_watch — объект, который изменился с момента вывода в консоль. А хочется увидить его состояние именно на момент вызова.
CASE DUO
Нет консоли? Пишем в адресной строке: javascript:alert(temp_var.objMethod()); void 0;
Пример №4
Ещё один пример. Возможно, немного странный. Хочется продебажить метод 3d-party-framework’а (например, ExtJS), но вот беда — нельзя тормозить JavaScript и нет доступа к исходному коду (правда странный пример? 🙂
Что же делать? Я делаю так:
Создаём файл с патчем: my-ext-patch.js, и подключаем его после ext-all.js
Внутри пишем что-то вроде:
Ext.form.Form.render = function (container) < // Wrap'им метод
// А вот и дебаг
console.log(container);
// Возможны варианты:
// console.dir(container);
// console.log(window.t = container);
// debugger;
Извращение? Возможно. Но мне нравится >:)
Эпилог
🐍 Найдите и исправьте ошибки в коде на Python: отладка с IDLE
Перевод публикуется с сокращениями, автор оригинальной статьи David Amos.
Выявление ошибок называется дебаггингом, а дебаггер – помогающий понять причину их появления инструмент. Умение находить и исправлять ошибки в коде – важный навык в работе программиста, не пренебрегайте им.
IDLE (Integrated Development and Learning Environment) – кроссплатформенная интегрированная среда разработки и обучения для Python, созданная Гвидо ван Россумом.
Используйте окно управления отладкой
Основным интерфейсом отладки в IDLE является специальное окно управления (Debug Control window). Открыть его можно, выбрав в меню интерактивного окна пункт Debug→Debugger.
Примечание: если отладка отсутствует в строке меню, убедитесь, что интерактивное окно находится в фокусе.
Всякий раз, когда окно отладки открыто, интерактивное окно отображает [DEBUG ON].
Обзор окна управления отладкой
Чтобы увидеть работу отладчика, напишем простую программу без ошибок. Введите в редактор следующий код:
Сохраните все, откройте окно отладки и нажмите клавишу F5 – выполнение не завершилось.
Окно отладки будет выглядеть следующим образом:
Обратите внимание, что панель в верхней части окна содержит сообщение:
Расшифруем: код for i in range(1, 4): еще не запущен, а ‘__main__’.module() сообщает, что в данный момент мы находимся в основном разделе программы, а не в определении функции.
Ниже панели стека находится панель Locals, в которой перечислены непонятные вещи: __annotations__, __builtins__, __doc__ и т. д. – это внутренние системные переменные, которые пока можно игнорировать. По мере выполнения программы переменные, объявленные в коде и отображаемые в этом окне, помогут в отслеживании их значений.
В левом верхнем углу окна расположены пять кнопок: Go, Step, Over, Out и Quit – они управляют перемещением отладчика по коду.
В следующих разделах вы узнаете, что делает каждая из этих кнопок.
Кнопка Step
Нажмите Step и окно отладки будет выглядеть следующим образом:
Обратите внимание на два отличия. Во-первых, сообщение на панели стека изменилось:
На этом этапе выполняется line 1 и отладчик останавливается перед выполнением line 2.
Здесь важно, что можно отслеживать растущие значения i и j по мере прохождения цикла for. Это полезная фича поиска источника ошибок в коде. Знание значения каждой переменной в каждой строке кода может помочь точно определить проблемную зону.
Точки останова и кнопка Go
Часто вам известно, что ошибка должна всплыть в определенном куске кода, но неизвестно, где именно. Чтобы не нажимать кнопку Step весь день, установите точку останова, которая скажет отладчику запускать весь код, пока он ее не достигнет.
Точки останова сообщают отладчику, когда следует приостановить выполнение кода, чтобы вы могли взглянуть на текущее состояние программы.
Чтобы установить точку останова, щелкните правой кнопкой мыши (Ctrl для Mac) по строке кода, на которой хотите сделать паузу, и выберите пункт Set Breakpoint – IDLE выделит линию желтым. Чтобы удалить ее, выберите Clear Breakpoint.
Установите точку останова в строке с оператором print(). Окно редактора должно выглядеть так:
Сохраните и запустите. Как и раньше, панель стека указывает, что отладчик запущен и ожидает выполнения line 1. Нажмите кнопку Go и посмотрите, что произойдет:
Теперь на панели стека информация о выполнении line 3:
На панели Locals мы видим, что переменные i и j имеют значения 1 и 2 соответственно. Нажмем кнопку Go и попросим отладчик запускать код до точки останова или до конца программы. Снова нажмите Go – окно отладки теперь выглядит так:
На панели стека отображается то же сообщение, что и раньше – отладчик ожидает выполнения line 3. Однако значения переменных i и j теперь равны 2 и 4. Интерактивное окно также отображает выходные данные после первого запуска строки с помощью функции print() через цикл.
Нажмите кнопку в третий раз. Теперь i и j равны 3 и 6. Если нажать Go еще раз, программа завершит работу.
Over и Out
Кнопка Over работает, как сочетание Step и Go – она перешагивает через функцию или цикл. Другими словами, если вы собираетесь попасть в функцию с помощью отладчика, можно и не запускать код этой функции – кнопка Over приведет непосредственно к результату ее выполнения.
Аналогично если вы уже находитесь внутри функции или цикла – кнопка Out выполняет оставшийся код внутри тела функции или цикла, а затем останавливается.
В следующем разделе мы изучим некоторые ошибки и узнаем, как их исправить с помощью IDLE.
Борьба с багами
Взглянем на « глючную » программу.
Вот неработающий код:
Введите этот код в редактор, сохраните и нажмите F5. Ожидаемый результат – _h_e_l_l_o_, но вместо этого выведется o_.
Если вы нашли, в чем проблема, не исправляйте ее. Наша цель – научиться использовать для этого IDLE.
Рассмотрим 4 этапа поиска бага:
Шаг 1: Предположение
Сначала вы не сможете точно определить местонахождение ошибки, но обычно проще логически представить, в какой раздел кода смотреть.
Обратите внимание, что программа разделена на два раздела: определение функции add_underscores() и основной блок, определяющий переменную со значением «hello» и выводящий результат.
Посмотрим на основной раздел:
Очевидно, что здесь все хорошо и проблема должна быть в определении функции:
Первая строка создает переменную new_word со значением «_». Промах, проблема находится где-то в теле цикла for.
Шаг 2: точка останова
Определив, где может быть ошибка, установите точку останова в начале цикла for, чтобы проследить за происходящим внутри кода:
Запустим. Выполнение останавливается на строке с определением функции.
Нажмите кнопку Go, чтобы выполнить код до точки останова:
Код останавливается перед циклом for в функции add_underscores(). Обратите внимание, что на панели Locals отображаются две локальные переменные – word со значением «hello», и new_word со значением «_»,
Нажмите кнопку Step, чтобы войти в цикл for. Окно отладки изменится, и новая переменная i со значением 0 отобразится на панели Locals:
Переменная i – это счетчик для цикла for, который можно использовать, чтобы отслеживать активную на данный момент итерацию.
Нажмите кнопку Step еще раз и посмотрите на панель Locals – переменная new_word приняла значение «h_»:
Это неправильно т. к. сначала в new_word было значение «_», на второй итерации цикла for в ней должно быть «_h_». Если нажать Step еще несколько раз, то увидим, что в new_word попадает значение e_, затем l_ и так далее.
Шаг 3: Определение ошибки и исправление
Как мы уже выяснили – на каждой итерации цикла new_word перезаписывается следующим символом в строке «hello» и подчеркиванием. Поскольку внутри цикла есть только одна строка кода, проблема должна быть именно там:
Код указывает Python получить следующий символ word, прикрепить подчеркивание и назначить новую строку переменной new_word. Это именно то неверное поведение, которое мы наблюдали.
Чтобы все починить, нужно объединить word[i] + » _» с существующим значением new_word. Нажмите кнопку Quit в окне отладки, но не закрывайте его. Откройте окно редактора и измените строку внутри цикла for на следующую:
Примечание: Если бы вы закрыли отладчик, не нажав кнопку Quit, при повторном открытии окна отладки могла появиться ошибка:
You can only toggle the debugger when idle
Всегда нажимайте кнопку Go или Quit, когда заканчиваете отладку, иначе могут возникнуть проблемы с ее повторным запуском.
Шаг 4: повторение шагов 1-3, пока ошибка не исчезнет
Сохраните изменения в программе и запустите ее снова. В окне отладки нажмите кнопку Go, чтобы выполнить код до точки останова. Понажимайте Step несколько раз и смотрите, что происходит с переменной new_word на каждой итерации – все работает, как положено. Иногда необходимо повторять этот процесс несколько раз, прежде чем исправится ошибка.
Альтернативные способы поиска ошибок
Использование отладчика может быть сложным и трудоемким, но это самый надежный способ найти ошибки в коде. Однако отладчики не всегда есть в наличии. В подобных ситуациях можно использовать print debugging для поиска ошибок в коде. PD задействует функцию print() для отображения в консоли текста, указывающего место выполнения программы и состояние переменных.
Например, вместо отладки предыдущего примера можно добавить следующую строку в конец цикла for:
Измененный код будет выглядеть следующим образом:
Вывод должен выглядеть так:
PD работает, но имеет несколько недостатков по сравнению с отладкой дебаггером. Вы должны запускать всю программу каждый раз, когда хотите проверить значения переменных, а также помнить про удаление вызовов функций print().
Один из способов улучшить наш цикл – перебирать символы в word:
Заключение
Теперь вы знаете все об отладке с помощью DLE. Вы можете использовать этот принцип с различными дебагерами.
В статье мы разобрали следующие темы:
Не останавливайтесь в обучении и практикуйте дебаггинг – это весело!