?

Log in

No account? Create an account

Пн, 26 дек, 2005, 01:09
Практика программирования

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

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

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

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

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

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

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

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

Пн, 26 дек, 2005 06:26 (UTC)
tnt23

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

Пн, 26 дек, 2005 08:06 (UTC)
egorius

Зубры электронных ламп и монстры ферритовых сердечников рассказывали, что в былые времена хороший специалист по БЭСМ-6 вдумчиво глядел на картину мигающих лампочек, и чувствовал, когда в программе что-то шло не так. Но я эти времена уже не застал, к сожалению :)

Пн, 26 дек, 2005 08:12 (UTC)
c_piper

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

Пн, 26 дек, 2005 08:41 (UTC)
tnt23

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

Пн, 26 дек, 2005 08:16 (UTC)
c_piper

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

Пн, 26 дек, 2005 08:53 (UTC)
dottedmag

Для PHP есть ZendDebugger.

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

Вт, 27 дек, 2005 09:20 (UTC)
c_piper

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

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

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

Вт, 27 дек, 2005 09:57 (UTC)
egorius

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

Ср, 28 дек, 2005 13:08 (UTC)
c_piper

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

Ср, 28 дек, 2005 19:39 (UTC)
egorius

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

Пн, 26 дек, 2005 09:01 (UTC)
egorius

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

Пн, 26 дек, 2005 08:25 (UTC)
dgemima

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

Пн, 26 дек, 2005 08:55 (UTC)
dottedmag

Только ошибки синхронизации - это замечательный пример HeisenBug. Очень часто отладочная печать в этих случаях заставляет программу работать правильно :(

Пн, 26 дек, 2005 09:59 (UTC)
dgemima: "Вы просто не умеете их готовить" (с)

Ну-у-у, надо ж не в лоб действовать - сначала в память, а по завершении критического куска - в файл. :-)

Пн, 26 дек, 2005 08:50 (UTC)
_pk_sly

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

Пн, 26 дек, 2005 09:04 (UTC)
egorius

Или разные стили? Каждому — своё?

Пн, 26 дек, 2005 09:08 (UTC)
_pk_sly

не стили, а методы.

каждому - своё, но не человеку, а багу 8)

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

Пн, 26 дек, 2005 15:31 (UTC)
sergg_rw

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

Пн, 26 дек, 2005 17:09 (UTC)
egorius

Эклипс — это сила, кто б спорил… Хочу Эклипс для PL/SQL! :)

Вт, 27 дек, 2005 09:18 (UTC)
sergg_rw

SQL development tool plugin for Eclipse:
http://www.eclipse.org/datatools/project_sqldevtools/index.html
Насколько в зачаточном состоянии не смотрел.

А вот Розу в интеграции UML с разрабатываемым кодом на Java они, ИМХО, уже переплюнули.

Вт, 27 дек, 2005 09:55 (UTC)
egorius

Похоже, весьма в зачаточном, но сам факт весьма радует!

Вт, 27 дек, 2005 06:25 (UTC)
_pk_sly

gdb позволит.