Практика программирования

[egorius]

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

Поковыряться-поковыряться, найти ошибку, залепить заплаткой и успокоиться? Да, это можно сделать довольно быстро. Но ведь в таком коде наверняка много ошибок, просто не все пока обнаружены. Переписать заново, красиво, аккуратно и с комментариями? Да, это может предотвратить потенциальные проблемы, и те, кто будут разбираться с кодом потом, может быть вспомнят добрым словом (кроме автора, наверное). Но это займёт много времени, поскольку придётся вникнуть во все детали. А времени, как всегда, не хватает.

Обычно, когда я вижу приличный код, я подавляю в себе желание перекроить его по моему вкусу. А тут не удержался.

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

Когда-то давно, во времена царствования Борланда, я пробовал гонять свою программу отладчиком. Ну как же, такое чудо! Программа работает, а в окошке видны значения переменных! И стек возвратов! Только почему-то оказалось, что отладочный print в нужном месте и внимательный взгляд на код позволяют найти ошибку гораздо быстрее. С тех пор я с недоумением смотрел на тех, кто при любой проблеме начинал тыкать в run to cursor, а они с недоумением смотрели на то, как я вписывал writeln.

Кстати, приятно было обнаружить тот же взгляд на вещи у Кернигана и Пайка в «Практике программирования»:

…вы можете оказаться в системе, в которой нет привычного вам отладчика. Некоторые программы не очень хорошо поддаются отладке… В таких ситуациях вы можете полагаться только на себя, и немногие вещи могут вам помочь: операторы выдачи сообщений на экран, личный опыт и способность рассуждать, глядя на код. … мы считаем пошаговый проход по программе менее продуктивным, чем усиленные размышления и код, проверяющий сам себя в критических точках. Щёлканье по операторам занимает больше времени, чем просмотр сообщений операторов отладочной выдачи, расставленных в критических местах. … Более важно то, отладочные операторы сохраняются в программе, а сессии отладчика преходящи.

Очень хорошая книга, если кто не читал.

Comments

[c-piper.livejournal.com]

хм... есть такие языки, для которых не предусмотрено графических сред программирования С ОТЛАДЧИКАМИ как в той же ВижуалСтудии(ну там отладчик - вообще мнямка). тот же ПХП, к примеру. тамочки только включать error_reporting(E_ALL) и тыкать echo или printf в каждой строчке при отладке.
хотя язык это нисколечки не портит.

[dottedmag.livejournal.com]

Для PHP есть ZendDebugger.

//и не надо про хороший PHP.

[c-piper.livejournal.com]

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

я не говорила, что пхп - хороший. и что плохой тоже не говорила.
он - ЯВУ, и судить его не мне. и как все ЯВУ имеет свои завихи и вывихи...

о языках можно говорить долго, поэтому не будем :-))

[egorius.livejournal.com]

Можно подумать, ЯНУ без вывихов :)

[c-piper.livejournal.com]

ну-у-у, ассемблеры - по своей природе - сплошной вывих.

[egorius.livejournal.com]

Вот она, суровая правда жизни. Куда не глянь — всюду вывих.

[egorius.livejournal.com]

Наличие или отсутствие отладчика вообще, по-моему, не может испортить язык. Это всё-таки уже среда разработки, а не язык как таковой. Можно сделать и для php отладчик. Но надо ли? Есть подозрение, что нет :)