Почему я дебажу код

Мне довольно странно было было узнать, что много из моих друзей –кодеров практически не пользуются дебаггерами. «Крайний случай», говорят.

В определённый момент кодинга под z80 (в 90-х) я осознал, что для того, что бы писать код – нужно мыслить как процессор. Звучит конечно странно, но полностью осознать довольно простую, по сегодняшним меркам, логику выполнения команд процессора помогает именно отладка своих программ. Кроме того – ответ на вопрос «КАК ИМЕННО ЭТО СДЕЛАНО!?» может дать лишь отладчик.



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

Почему? Потому что я уверен, что далеко не всё я могу в своей голове удержать, потому что проверка даёт уверенность в правильной генерации данных / кода / выполнения подпрограмм. Таким образом я УВЕРЕН, что написанные части работают именно так как хочу Я, а не проц.

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

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

Конечно, не обязательно использовать отладчик для «мёртвого кода» :), написанного вами тысячи раз. Но и на старуху бывает проруха – невнимательность, забывчивость, давно заброшенный код, который вы писали в другом состоянии и с другим опытом.

Прикол был, когда у ААА появились новые московские диски и он их считывал в trd. Читалось не всё, и некоторые демы он прислал мне, дабы я выяснил – работают ли они вообще. Замечательно, скажу я вам, было глянуть на BestDemo5, которая после старта выдавала бред на экран и сбрасывалась. Дема была круто по тогдашним меркам заксорена, но! После бреда на экране и «сброса» стояло ожидание нажатия на пробел :) И потом, естественно, демо запускалось :))

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

Дело ваше, конечно, голова большая :)
  • avatar
  • [просмотров: 5413]
  • +7

33 комментария

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

Хотя бывает всякое. Очень неприятный баг сидел в бетах In Memoriam VNN, случайные сбои неясной природы, ошибку нашёл в отладчике g0blinish, оказалось, что распаковщик портил IY, а т.к. он был сделан частью загрузчика, глядя на код ничего увидеть было нельзя (сам-то код начинался с DI: PUSH IY).
avatar
такая же байда была в игре. искал, где-то память портилась, всё валилось в разные моменты.
в результате обнаружил, что ayFX player огородил для себя мало памяти и запортил содержимое кода :) вылавливалось при воспроизведении звука :)

Но! когда игра стала со звуком! ООоооо))
avatar
а я отлаживаю ВСЕГДА, когда это не напряжно. зато уверен в коде. но, конечно, всех ошибок это исправить не поможет, но зато не надо становиться процессором:)
  • psb
  • +4
avatar
Мне кажется, что это ложное противопоставление! Например, я тоже стараюсь всё отлаживать, просто обычно не в отладчике.
avatar
а я именно в отладчике, каждую команду вновь написанной процедуры. это разные подходы.
avatar
Т.е. тестированию во входным/выходным данным не доверяешь? Если что, я осознаю возможное кол-во внутренних состояний :)
avatar
Ну тут скорее всего имеется ввиду «проверить» что бы то, что написано в ассемблере, так же выглядело и в дебаггере :) Ибо бывали случаи несоответствия, что как ты понимаешь вызывало фантомные глюки.
avatar
«доверяй но проверяй»
avatar
Вопрос в способе проверки. Скажем, свои AY плейеры я дебажу в процессе работы — на слух, а перед релизом — пишу дамп проигранного трека и сверяю его с исходным заведомо корректным дампом. Я не считаю это худшей проверкой, чем торчание в эмуляторе, т.к. проверяются тысячи комбинаций параметров.
avatar
Ого, TDD на асме :) А подробнее можешь рассказать? Как в подобном случае assert делать? lua?
avatar
Ну, это громко сказано. У меня тест = конечный прод по сути. Какие-то модули могут быть осмысленными в отрыве от всего, но идеи конечно похожи на TDD, в том плане, что я всегда начинаю с полной сборки «пустой» демы, а потом просто пишу её по порядку, удостоверясь по ходу, что всё работает как задумано. Т.е. вначале дема просто пустышка с музыкой, а потом добавляются и отлаживаются прямо там же эффекты. Добавление эффекта, докручивание эффекта — всё это облегчено ядром с явным скриптом и полностью автоматической сборкой.
avatar
нет. моя практика показывает, что
1. запросто можно опечататься, либо же допустить другую мелкую (в т.ч. логическую) ошибку,
2. а главное, код нередко работает «случайно»! это очень стремный тип бага. т.е. ты проводишь эксперименты, все работает. а потом он внезапно начинает глючить… это всякие неиниц. переменные, обращения в чужую память и все такое. один внимательный проход дебаггером по всем веткам программы убирает большинство таких косяков.

почему этого не делать в уме/при написании — уже говорили, лень становиться процессором.
avatar
Я тебе честно скажу, у меня мозг так и так как процессор работает :)
Реальные проблемы чаще всего бывает когда тыкаю в сырце символ случайно, но это бывает обычно уже после стадии проверки и любым способом плохо ловится (было пару раз).
avatar
Постоянно сижу в отладчике. Очень сильно не хватает нормального «человеческого» отладчика для Unreal. Что бы можно было растянуть окошки, открыть сразу несколько вкладок с разными участками память, сделать окошко дебага больше итд. итп.

А по поводу нужности данного процесса, пока ты колупаешь чисто свой код и постоянно в тонусе (то есть помнишь что, где и как писал) это всё замечательно. Но как только начинаешь что-то писать под «чужие» проекты, например плагин для WildCommader, то сразу понимаешь насколько у людей разное мышление, логика и сколько «сюрпризов» может преподнести скудная документация.

Ну уж про варианты когда после сборки монолоадера работа просто сбрасывается в определённый момент загрузки я уже молчу вообще :) Это сейчас хорошо можно делать SPG, паковать всё это дело mhmt и быть на 99.9% что всё запустится как надо. Но есть люди которые ещё до сих пор выпускают релизы в TRD и их не мало.
avatar
У меня как-то не сложилось с отладчиками. Причем в том смысле, что если уж я впорол косяк, то отладчик мне, как правило, ничем помочь не может )
avatar
Имхо картинка от z80 Simulator IDE просто неудачная, вся работа в проге — просто кошмар, увешанный gui-рюшечками.
Код я дебажу иногда, когда после ассемблирования снапшота что-то не работает или работает криво. Для этого подходит отладчик Spectaculator. Единственный минус по сравнению с древним SDTS2.6 — экран обновляется после инта, а не сразу. Отладчик в унрыле — скорее всего атавизм, лучше бы подошел аналог из bgb — просмотр тайлов, карты тайлов и пспрайтов.
а в целом иногда отладка сводится к Атари, если привыкнуть, то отладчик из Altirra более удобен, чем в Atari800winplus.

Почему я дебажу код? потому что по невнимательности пропускаю ошибки.
avatar
насчёт картинки — нашлось по принципу «много разных окон дебаггера», это скорее «картинка для привлечения внимания» :)
Анрил мне очень нра, пусть даже для ТС он ещё не заточен как нужно.
А Spectaculator-а просто не хватает по возможностям/удобству. Либо я не приучился ним пользоваться.

а дебажу я всегда :)
avatar
Что меня привлекает в Спектакуляторе — это заявленные conditional breakpoints, но так и не появившиеся. Может быть, тогда отловлю ошибки в стареньких демо эффектах.
avatar
Пацаны, Spin это умеет делать, причём довольно давно.
avatar
Дизайн картинки ровно такой, как я хочу для анрыла. Особенно полезна раскраска в верхнем окне — идеально. Глаза не устают, и все видно.
avatar
все же пожелание остается в силе. Просмотр видеопамяти ускорит разработку и поиск ошибок.
avatar
Да, полностью плюсую, видел такое в С64.
avatar
примерно вот так
avatar
Ага, схоронил для справочки.
avatar
А почему я дебажу код? Потому что бывает тупо лень оттрассировать в мозгах логику собственного софта, что однозначно необходимо делать ДО отладки.
  • tsl
  • 0
avatar
Обявляю соревнование.
Тот, кто выдаст ВСЕ коды к скрытым загружающимся частям OSCOSS, я выставлю лучший коньяк что я нахожу в магазинах.
Отправлю в Россию :)

не шутка.
  • VBI
  • +2
avatar
Все коды может выдать только Robus (если помнит). Корректнее ставить условие, кто больше кодов выдаст )
avatar
Всё правильно. Вот кто-то назовет два кода, а остальные забьют. И что, высылать такому «хакиру» коньяк?

А так, в худшем случае VBI остается при своих. Ну а если даже кто-то найдет все коды… ТАКОМУ — НЕ ЖАЛКО!

Вова, я правильно мысль уловил?
avatar
Дык все — это сколько? Нашел кто-то 48 кодов — а их может 49 — непонятна. Коньяк выпит — а через неделю еще пара кодов нашлась, что делать?
avatar
Я полагаю, Robus скажет Вовчику их количество, ради такого-то дела.
avatar
Ради такого дела он и коды все сказать может сразу )
avatar
ну почему. в принципе тема тянет на конкурс. другое дело, если no hype и лениво :)
avatar
ну естественно всё будет проверено мастером :))

кому коньяка? 5 звёзд, все дела! :)
nyuk , именно — не жалко.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.