Вспоминается Фортран, но это справедливо для всех языков. Иногда авторы языка допускают ошибки. С моей точки зрения, в языке Си полно ошибок.
Сейбел: Каких, например?
Крокфорд: Например, оператор switch изначально является неудачным, не нужно было делать его таким. У оператора ++ огромные проблемы в смысле безопасности, поскольку он провоцирует вас на разные хитрости и попытки сделать слишком многое в одной строке кода. В результате код становится трудным для понимания, что часто приводит к различным ошибкам, таким как переполнение буфера. Так что большинство проблем безопасности, которые мы наблюдаем в операционных системах последние пять лет, связаны с использованием оператора ++.
Обычно я вообще не использую оператор ++. Бывает, его можно использовать, но чаще нет, и мне трудно различить эти случаи в своем коде.
Сейбел: Но ведь можно возразить, что проблемы безопасности, связанные с оператором ++, возникают не из-за самого оператора ++, а из-за отсутствия проверки выхода за границу массива или из-за проблем с обычными указателями. В Java нет подобных проблем с безопасностью, поскольку если есть оператор ++ и происходит выход за границу массива, то получается исключение.
Крокфорд: Да, в Java это менее опасно. А в JavaScript такой опасности совсем нет, поскольку там отсутствуют массивы. Но в любом случае, отказавшись от этого оператора, я заметил улучшение качества моего кода, просто потому что перестал записывать выражения в одну строку.
Другой пример — оператор continue. Я еще не встретил ни одного фрагмента кода, который не смог бы улучшить, выкинув оператор continue. Да, с его помощью легче создать какую-то сложную конструкцию. Но я заметил, что всегда могу улучшить эту конструкцию, найдя способ выкинуть его. Так что лично я никогда не использую оператор continue. Если же я вижу continue в своем коде, значит, что-то недодумал.
Сейбел: Как вы читаете чужой код?
Крокфорд: Путем чистки: я переношу его в текстовый редактор и начинаю править. Начинаю с пунктуации и отступов. У меня есть для этого специальные программы, но я предпочитаю делать это вручную, поскольку так ближе знакомишься с кодом. Этому меня научил Мор-нингстар. Он блестяще проводил рефакторинг чужого кода, всегда применял этот подход и доказал его эффективность.
Сейбел: Вам встречался код, который поначалу выглядел сумбурно, но после чистки вы понимали, что на самом деле он хорош?
Крокфорд: Нет, такого никогда не случалось. Мне кажется, очень сложно небрежно написать хороший код (под хорошим кодом я понимаю читаемый). На этом уровне совершенно неважно, что означает этот код для машины, если я не могу понять, что он должен делать; он может оказаться удивительно эффективным, или компактным, или потрясающим еще в каком-то смысле, но это уже неважно.
Сегодня читаемость кода — мой главный приоритет. Она важнее эффективности и почти так же важна, как корректность, и я думаю, что читаемость кода — важнейший шаг к его корректности. А если код тяжело читать, то, по-видимому, разработчики выбрали неверные компромиссы, и нельзя этот код назвать хорошим.
Сейбел: А как насчет глубоко вложенного цикла, который должен выполняться невероятно быстро? Должен ли весь код быть читаемым — или иногда читаемость можно принести в жертву эффективности?
Крокфорд: Думаю, иногда можно пожертвовать читаемостью, но в таком случае я пишу целый роман, по обе стороны этого блока кода, с объяснением того, почему мы делаем то, что делаем. Обычно это упускают из виду. И я не раз видел, как люди боролись за эффективность, когда это совершенно не требовалось. Они не знали, на что тратит время их собственная программа, и оптимизировали код, не требующий оптимизации, поскольку он никогда не изменится настолько, чтобы его выполнение существенно влияло на общую производительность. От такой оптимизации нет никаких выгод или преимуществ, она лишь вносит дополнительный хаос. Я неоднократно встречал такое.
Сейбел: В языках программирования с фигурными скобками программисты ведут бесконечные холивары («священные войны») по поводу того, где расставлять эти скобки, доказывают, что тот или иной стиль делает код более читаемым. Занимаясь чисткой кода, вы приводите его в форму, облегчающую восприятие?