Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
Сейбел: Вы придерживаетесь каких-либо правил относительно количества комментариев?
Козелл: Я не добавляю в свой код слишком много комментариев, так как считаю, что он сам по себе должен быть читабельным и ясно выражать твои алгоритмы и мысли. Пишу комментарии к подпрограммам с кратким описанием того, как они действуют и как к ним обращаться - что делать, когда возникают исключения, какова последовательность аргументов и так далее. Но сам по себе код должен ясно выражать, что ты делаешь с его помощью.
Я добавляю комментарий в код, только если инстинкт говорит мне: “Этот конкретный участок кода, хотя и работает, не совсем ясно показывает, что я хочу сделать”. Тогда я пишу: “Этот код сортирует таблицу”, если по каким-то важным для меня причинам он не очень похож на стандартный предназначенный для этого код.
Я никогда не был фанатом структурированных программ, где каждая подпрограмма сопровождается 18-строчным комментарием и все аргументы идут в строгом порядке. Я не структурирую свои программы настолько тщательно. Какие-то из моих подпрограмм могут быть длинными, другие - короткими. Меня беспокоит общая структура программы, так сказать, расположение фигурных скобок.
Одна из причин состоит в том, что я смотрю на работу кода в целом, а не его отдельных частей. Так, встретив инстукцию if, я вижу условие. Я мысленно отвечаю на это условие “да” или “нет”, и если хочу пропустить тело инстукции if, то код должен позволить мне перейти к тому, что идет после этой инстукции, не особо вникая в синтаксис. То есть я из тех старомодных парней, которые любят, чтобы открывающая и закрывающая скобки стояли одна под другой.
Если все делать по-моему, то код будет выглядеть так: “оператор, открывающая скобка, закрывающая скобка; оператор, открывающая скобка, закрывающая скобка”, - это позволяет видеть последовательность операторов. Кроме того, как я уже сказал, если открывающая скобка находится слишком далеко от закрывающей, значит в нее заключено слишком много всего и это надо оттуда убрать. Иногда я убираю даже не очень большие куски кода, заключенные в скобки, если не могу понять, что эта ветка программы делает и зачем в ней весь этот бардак.
Я всегда стараюсь задвинуть бардак подальше, поместить его в такое место программы, где он не мешал бы понимать структуру и работу кода. Мне тяжело воспринимать некоторые стили программирования, не предусматривающие ясную структуру. Интересно, что у автора языка Python мозги, похоже, устроены в точности как у меня. Он разом избавился от проблем с синтаксисом кода, потому что у него не требуется открывать и закрывать скобки. Если ты видишь инстукцию if, то открывающая фигурная скобка неявно будет рядом, как и закрывающая. И если хочешь пойти по коду дальше, то он будет выровнен по этому if. Я работаю с Си и Perl, предполагая, что в Python то же самое: можно нажать кнопку, и вся программа сворачивается тдк, что видишь только ее общую структуру.
Я не сторонник войн вокруг стилей с аргументацией “этот стиль уродливый”. Хочется думать, что если я и ввязываюсь в такие войны, то только если это касается моего понимания структуры кода. Такое понимание всегда было моей сильной стороной. Пока вы не докажете, что понимаете код лучше меня, убедить меня в правильности вашего подхода будет чрезвычайно сложно.
Сейбел: Получается, беспристрастный анализ незнакомого кода и его отладка - особые навыки, присущие не всякому хорошему программисту?
Козелл: Конечно. И здесь есть два аспекта. Был еще один парень, Стив Баттерфилд. Он тоже был хорошим отладчиком, но представлял собой полную мою противоположность. В жизни не встречал другого человека, настолько хорошо исправлявшего программы и при этом совершенно в них не разбиравшегося. Он мог взять программу и исправить маленький кусочек где-то у нее в середине, изменив ее работу. В больших, сложных программах Стив мог исправлять какие-то мелочи, заставляя их работать лучше в некотором отношении, но, по-моему, только ухудшая общую картину.
Я же всегда стремился улучшить программу в целом и старался понять ее всю, даже если в исправлении нуждался лишь маленький кусочек. Я всегда разберу все с самого начала, вместо того чтобы сказать себе: “Вот это не работает. Исправь здесь”. Так что порой я трачу слишком много времени на то, чтобы загрузить весь код себе в голову, хотя хватило бы быстрого локального вмешательства.
Но когда Стив уходил из проекта, как правило, выяснялось, что править код после него чрезвычайно трудно. Я старался поддерживать все в хорошем состоянии, но если программа была огромной и ужасной, мне приходилось долго работать впустую, прежде чем приняться за реальную работу. Впрочем, такое случалось нечасто, потому что я, как правило, отлаживал программу иначе.
Как уже сказано, я зачастую не имел ни малейшего понятия где именно находится баг. В какой-то момент я говорил себе: “Этот участок кода должен делать то-то и то-то, но не похоже, что он действительно это делает. Зачем вообще было писать такой сложный код для такой простой операции?” Так что я просто выкидывал этот кусок и заменял его подпрограммой, которая делала то, что он должен был делать. И программа сразу, как по волшебству, начинала работать. Если разобраться, то дело, как правило, было в том, что программа развивалась и ее части должны были развиваться вместе с ней. А автор предпочитал исправить старую подпрограмму, вместо того чтобы заменить ее новой, и где-то ошибался.
Я такое никогда не отлаживал. День или два я набирал новый код, никто толком не понимал, что я делаю, но в итоге все начинало работать. Да он же гениальный наладчик! На самом деле, это очень опасно: Уилл, в общем, прав, и переписывая сто строк кода, рискуешь, исправив один баг, добавить шесть новых. Причем о первом ты хотя бы уже знал в то время, а новые шесть надо было еще найти. Но у меня все получалось: год за годом я переписывал код, и в итоге почти всегда все работало.
Сейбел: Значит, у вас должны быть какие-то стратегии чтения кода. Допустим, исправлять ничего не надо, просто перед вами большой кусок кода, который нужно разобрать. Как вы с этим справлялись?
Козелл: Как показывает опыт, не слишком хорошо. Одна из причин, по которой я скорее перепишу фрагмент кода, чем стану его исправлять, заключается в том, что после какого-то момента я уже не могу его разбирать. Я не читаю код, как книгу. Я пытаюсь понять, что программа делает, и затем ищу подсказки в коде, двигаясь от общего к частному.
Читая программу, я одновременно думаю, как бы я решил связанную с ней задачу. То есть ищу те места, в которых смогу сказать: “О, вот тут программа делает то-то”. Нередко после этого я со свойственной мне самоуверенностью могу сказать, что автор написал эту часть неправильно. Или, по крайней мере, понимаю, что было сделано не так, как сделал бы я.
