При просмотре сообщений на форуме glscene.ru, в основном, осознал, как мало людей сейчас могут нормально debug'ить свой проект. это настолько удручает, что я решился написать данный текст.
Во-первых: зачем нужен debug вообще? Ну, стоит, наверно, вспомнить моменты, когда ваша собственная программа ведет себя не так, как Вы планировали. "Как ей не стыдно вообще?" - думаете Вы в такие моменты - "я же её создатель!". Или выдает ошибки с непонятным для Вас текстом. как быть? что предпринять? тут я должен Вам поведать первое правило: последнее, что надо делать, это постить где-либо Ваш код и вопрос "а почему ошибка?" такие действия выдают Вас как неопытного программиста, который пишет свой код, не разбираясь, как он работает. после такого сообщения, все более-менее адекватные форумчане понимают, что Вы - не умеете программировать в принципе. Почему? Да просто потому, что это Ваш собственный код! Вы его написали и должны бы знать, как он работает лучше остальных!!! Если Вы сами не понимаете, почему ошибка - значит Вы не понимаете как работает Ваша программа. Бывают случаи, когда ошибка происходит не в Вашем коде, а в сторонних библиотеках, используемых программой. в этом случае стоит также внимательно поdebug'ить сторонний код или почитать мануал к библоитеке, если ее код закрыт, далее поискать в системе Google на предмет подобных вопросов и только после этого спрашивать на каких-либо форумах. При этом стоит четко понимать, что скорее всего проблема в использовании Вами этой сторонней библиотеки (ведь у большинства таких же как Вы все нормально).
Во-вторых: что такое debug? тут все просто - Ваша программа работает по определенному алгоритму, который она сама и представляет. если этот алгоритм расходится с тем, что Вы планировали увидеть, значит Вы должны найти моменты, в которых алгоритм из Вашей головы (а еще лучше - из листочка, исписанного Вами блок-схемами) расходится с алгоритмом программы. как найти эти расхождения? довольно просто - значения различных переменных, заход программы не в планируемые ветки условий, вызов "не тех" методов и функций - эта информация должна Вам помочь понять, что именно происходит не так, как планировалось.
Итак, начнем! Здесь я буду рассматривать только среду Delphi (лично у меня Delphi 7). и основные средства дебага буду указывать этой среды.
Главное, что должно стать вашим другом - это BreakPoint'ы ("точки", "бряки", "брэкпоинты" и другие транслитизации). Итак, что такое breakpoint? это место, дойдя до которого, программа должна приостановиться. как указать такую строку? breakpoint можно поставить/снять следующими способами: кликнуть на полосу слева от кода в нужном месте или нажать F5 (тогда breakpoint встанет на строку с курсором).
кстати, через контексное меню breakpoint'а можно задать еще и условие (и много чего другого безумно полезного, но не будем об этом пока), при котором программа должна остановиться на данной строке. чем нам может пригодиться breakpoint? ну, сразу можно приостановить программу в нужный момент и начать смотреть построчно, что делает сама программа. при этом нам доступна информация обо всех переменных, о которых знает программа в этот момент. проверить на nil что-либо или дописать classname к объекту класса является первым делом при ошибках типа "Access Violation". как посмотреть значения переменных? существует множество способов... иногда достаточно просто навести курсор мыши на нужную переменную - в подсказке всплывет ее значение в данный момент. но чаще требуется посмотреть более сложные переменные (поля объектов или записей, сравнить адреса памяти и другое) или даже изменить их значения. лично я чаще всего пользуюсь окном Evaluate/Modify, которое вызывается при помощи Ctrl + F7.
также можно "забросить" интересующие нас переменные в Watches'ы (View->Debug Windows->Watches или Ctrl+Alt+W). отличием от предыдущего окна является то, что обновление данных происходит моментально, а в Evaluate/Modify необходимо каждый раз нажимать enter, чтобы посмотреть на обновленное значение переменной.
не отрабатывает какая-то ветка условий? что нужно делать? поставьте breakpoint с нужным условием в нужном месте программы. если при необходимых действиях программа там не остановилась - значит условие не вылоняется или же программа не проходит эту строку, и стоит искать ошибку в выставлении каких-то флагов или еще чего-то, что используется, достаточно смотреть какие, когда, и где переменные меняются и почему (из-за этого, кстати, я советую для property классов не лениться и использовать get'еры и set'еры, чтобы можно было с легкостью поставить в эти методы breakpoint и ждать, когда кто-то начнет менять значение свойства класса).
также важным бывает "а откуда мы пришли сюда"? то есть, допустим, мы поставили breakpoint в set'ер property объекта класса, но кто меняет сейчас это свойство? конечно, можно использовать F7 для выхода из set'ера и "раскручивания" списка вызовов. но можно вызвать окно Call Stack (View->Debug Windows->Call Stack или Ctrl+Alt+S) и увидеть этот список воочаю. ведь не только из одной ветки вызовов мы могли очутиться на поставленном breakpoint'е. взгялнув на стек чаще всего мы нажмем F9, запустив программу дальше, и будем ждать, пока не сработает нужная нам ветвь вызовов.
согласен, это основы, и их знает большинство. значит этот текст для "меньшинства". может буду его обновлять и дополнять... и он когда-нибудь кому-нибудь да и пригодится...
вот как-то так, на этом пока все))
0 коммент.:
Отправить комментарий