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

[egorius]

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

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

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

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

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

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

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

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

Comments

[tnt23.livejournal.com]

Особенно хорошо (в смысле плохо) с отладкой всяких embedded вещей, где либо еще нет JTAG, либо архитектура ну совсем уж экзотическая. Приходится пробавляться всевозможными выводами в буфер экрана, маханьем хвоста и двиганьем ушами морганиями светодиода и спикерной морзянкой.

[c-piper.livejournal.com]

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

[dgemima.livejournal.com]

А вот при поиске ошибок синхронизации отладочная печать - это вообще единственный действенный метод. Ну, после вдумчивого изучения кода, конечно. ;-)

[-pk-sly.livejournal.com]

это разные методы. каждый - для своего.

[sergg-rw.livejournal.com]

Единственный отладчик, в котором я иногда забываю про отладочный вывод - отладчик для Java в Eclipse, ну кто вам еще позволит после остановки на breakpoint'е вызвать у объекта метод или написать целое выражение для вычисления (даже с побочными эффектами :)