Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Re: Использования дебаггера, чтобы разобраться как работает
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
дело вкуса
А философски неверно писать программы с ошибками
Надо писать сразу без ошибок, тогда и дебаггеры, логгеры и прочие юнит-тесты не будут никому нужны.
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Если это помогает разобраться быстрее — значит правильно, если нет — значит неправильно
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Если разбираешься и поддерживаешь чужой код, то да — без отладчика порой не обойтись. Когда пишешь сам, то я предпочитаю использованию отладчика качественное проектирование и аккуратное кодирование. Во всяком случае стремлюсь к тому, чтобы обойтись без него.
P.S. Кажется Дейкстра сравнивал отладчик с костылями
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, ton4eg, Вы писали:
T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
J>дело вкуса
J>А философски неверно писать программы с ошибками J>Надо писать сразу без ошибок, тогда и дебаггеры, логгеры и прочие юнит-тесты не будут никому нужны.
Дык код не свой! Код чужой и нада его править. Свой понятно был бы без ошибок и понятный
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Дык код не свой! Код чужой и нада его править.
Сначала нужно его понять. Отладчик и логи это крайний случай, для проверки теорий.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Использования дебаггера, чтобы разобраться как работа
log("enter");
if ( full_moon_madness() ) log ("full_moon_madness");
log("exit");
наблюдая вывод, 2е сообщение можно увидеть, а можно и нет нет.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, ton4eg, Вы писали:
T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
F>Если разбираешься и поддерживаешь чужой код, то да — без отладчика порой не обойтись. Когда пишешь сам, то я предпочитаю использованию отладчика качественное проектирование и аккуратное кодирование. Во всяком случае стремлюсь к тому, чтобы обойтись без него.
F>P.S. Кажется Дейкстра сравнивал отладчик с костылями
Костыли гораздо лучше дебаггера.
С костылями можно найти оригинального разработчика и надавать ему этими костылями по шее.
А дебаггером — что ты ему сделаешь...
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Надо быть идиотом чтобы не пользоваться инструментом который ускоряет решение проблем.
Отладчик это лог на стероидах. Он позволяет куда более интерактивно исследовать происходящее в коде.
Логи тоже имеют свои преимущества. Они не блокируют выполнение и они позволяют видеть происходящее в динамике.
Это два взаимодополняющих средства поиска ошибок. Если у вас нет ошибок, то вам не нужны ни логи, ни отладчик. Но тогда скорее всего вы не программисты.
ЗЫ
Больше всего разговоров о ненужности отладчиков исходит от тех кто пользуется средствами разработки не имеющими отладчиков вовсе или имеющие отладчики плохого качества. Далее чтобы успокоить свое сознание (которое понимает, что что-то не так) они сами себе проводят внушение, что мол, отладчики не нужны и даже вредны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Использования дебаггера, чтобы разобраться как работа
VD>Отладчик это лог на стероидах. Он позволяет куда более интерактивно исследовать происходящее в коде. VD>Логи тоже имеют свои преимущества. Они не блокируют выполнение и они позволяют видеть происходящее в динамике. VD>Это два взаимодополняющих средства поиска ошибок. Если у вас нет ошибок, то вам не нужны ни логи, ни отладчик. Но тогда скорее всего вы не программисты.
Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
А какие логи ты хочешь читать, чтобы понять чужой код? Те, которые создает автор исходного кода? А откуда ты знаешь, что он туда пишет и насколько подробно?
Или те логи, записи в которые которые ты будешь сам вставлять по коду? А как ты сможешь их осмысленно вставить, если пока еще не понимаешь, как работает код?
Если ты хочешь туда понавставлять вывод разных переменных — то это будет тот же отладчик только в профиль. Разница будет — исключительно в динамике и удобстве, как сказал Vlad
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
Совершенно нормально. Если ты не понимаешь как функционирует код, то ни исправить ошибки не выйдет, ни изменить. Точнее может и выйдет, но потом с огромной вероятностью придется искать ошибки.
Другой вопрос, что код в котором без отладчика ничего не понять — это плохой код.
Конечно нужно стараться писать код который очевиден как божий день. Но если уже есть код, и в нем нужно разбираться, то отладчик и логи отличные средства для этого.
Я вот скажу честно... В коде компилятора Nemerle мне помог разобраться именно отладчик. С его помощью я исправил кучу багов и нехило доработал компилятор. В это же время авторы языка пасовали, так как использовали только логи для отладки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Почему не правильно? Считай, что дебаггер это тот же расширенный лог на каждой строке. Плюс вывод некоторого окружения этой строки. С другой стороны дебаггер ограничен скоростью человека. Поэтому при выполнении сложных увесистых алгоритмов пользы от него мало. Особенно, если нужный эффект проявляется, скажем, на 19624-й итерации. Тогда нужна изобретательность. А вот лог можно потом проанализировать автоматическими средствами.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Для того чтобы понять как работает код — дебаггер является хорошим инструментом в том плане, что он позволяет отследить цепочку вызовов и состояние памяти на пути этой цепочки. В более-менее сложном коде порой бывает сложно проследить, что, кого, когда, зачем зовет. Но это только небольшая часть. Я бы сказал что хорошие тулзы анализа кода/навигации по коду вносят гораздо больший вклад.
Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
M>Почему не правильно? Считай, что дебаггер это тот же расширенный лог на каждой строке. Плюс вывод некоторого окружения этой строки. С другой стороны дебаггер ограничен скоростью человека. Поэтому при выполнении сложных увесистых алгоритмов пользы от него мало. Особенно, если нужный эффект проявляется, скажем, на 19624-й итерации. Тогда нужна изобретательность. А вот лог можно потом проанализировать автоматическими средствами.
Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
The God is real, unless declared integer.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, netch80, Вы писали:
N>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
Можно, но часто это бывает следствие бага на 7286-й итерации.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
M>Можно, но часто это бывает следствие бага на 7286-й итерации.
Совершено не обязательно ставить условие на номер итерации. Вариантов масса. Другое дело, что нужно заранее представлять, что пытаешься найти, а не просто шарить вслепую.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Наиболее филосовски верное решение — распечатать ассемблерный код программы, обклеить им всю стену, сесть перед ней в позе йога и сидеть до полного просветления.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
Кэр>Совершено не обязательно ставить условие на номер итерации. Вариантов масса. Другое дело, что нужно заранее представлять, что пытаешься найти, а не просто шарить вслепую.
Для того, чтобы понять, что надо найти, надо проводить диагностику. Скажем так, была такая проблема: я писал решатель цумэ-го и при прогоне тестов ряд из них пе
Опять же, это очень хорошо, когда ты знаешь, что надо найти... На практике ситуация зачастую несколько другая. Например, при реализации алгоритма решения цумэ-го я добился того, что он решает простые задачи. После введения одной оптимизации вдруг при решении одной задачи начал появляться неправильный ответ. В процессе решения строится дерево позиций, на которое нетривиальным образом наращиваются новые узлы. Очевидно, что в одном из узлов вернулась неправильная оценка, но как понять в каком из и на какой итерации?
При решении таких вопросов очень хорошо себя проявили дампы этого дерева позиций и добавление отладочного кода. Чистая отладка начиналась уже после момента диагностики ошибки, а зачастую и не требовалась...
