Вы можете задаться вопросом, какое отношение серая футболка Цукерберга имеет к правилам кодирования. Надеюсь, ты скоро это поймешь. В этой статье я попытаюсь объяснить, почему использование руководств по кодированию отвечает интересам всех, включая программиста, читателей (обычно других разработчиков) и руководство.

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

Почему рекомендации полезны для вас, если вы читатель?

Очень важным аспектом является то, что вы, как читатель, знаете, чего ожидать. Рекомендации устанавливают ожидания относительно того, как будет выглядеть код. Если вы видите определенные имена (класс, функция, имена переменных и т. д.), вы — как читатель чужого кода — точно знаете, какого вида (например, статического, локального, параметрического и т. д.) ожидать независимо от того, кто написал тот кусок кода.

Читать код, который соответствует определенному стилю, согласованному с организацией, легче и быстрее. Это означает, что как читатель/рецензент вы можете сосредоточиться на всем коде, а не просто пытаться собрать все воедино построчно. В конце концов, это может и в большинстве случаев повысит качество. Также ваше удовлетворение как читателя! Я почти уверен, что вы чувствуете себя счастливее, когда быстро что-то понимаете.

Когда мы говорим о чтении кода, давайте не будем забывать, что код пишется только один раз (затем, конечно, он (д)эволюционирует), но его будут читать другие гораздо чаще. Как писали Х. Абельсон и Г. Сассман: «Программы предназначены для чтения людьми и лишь случайно для выполнения компьютерами». [1]

Так что определенно стоит потратить время на то, чтобы сделать кусок кода читабельным. Это приведет к более быстрой реализации патчей и исправлений. Но, как я уже писал, качество повысится за счет использования направляющих, поэтому вам понадобится меньше этих исправлений.

Почему рекомендации полезны для вас, если вы разработчик?

Доволен будет не только рецензент, но и автор. Кому нравится получать несколько страниц отзывов об именах переменных, непоследовательном стиле кодирования и длинных функциях?

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

Хотя один стиль не обязательно лучше, чем у других, обычно рекомендации по кодированию пишутся разработчиками, имеющими больше опыта, чем в среднем. За ними стоит множество полезных мыслей, над которыми стоит задуматься. Если вы внимательно прочитаете рекомендации, вы можете найти такие тонкости, которые вы бы не нашли самостоятельно некоторое время.

И, конечно же, через несколько месяцев вы сможете и, возможно, станете читателем собственного кода. А теперь подумайте и спросите себя. Сколько раз вы мысленно ругались, спрашивая, что, черт возьми, делает ваш код, который вы написали несколько месяцев назад? Был ли это чистый код, соответствующий стандартам?

Почему рекомендации полезны для вас, если вы менеджер?

Если вы менеджер, я думаю, вы уже убедились в том, что прочитали. Больше довольных сотрудников, лучшее качество, меньшее число невыполненных задач? Что еще тебе нужно? Есть еще как минимум одна вещь. Использование руководящих принципов снижает инвестиции, необходимые для привлечения новых разработчиков. Если новичок понимает код быстрее, он(а) начнет вносить ценный вклад раньше, и, кроме того, новый разработчик также будет проверять более чистый код, поскольку он(а) будет следовать стилю других вокруг.

Где эта футболка?

К настоящему времени я рассказал вам, почему я убежден, что руководства по написанию кода хороши для читателей, разработчиков и полезны для руководства. Но я так и не объяснил, при чем тут одежда Цукерберга или Обамы.

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

Принятие решения требует энергии, и это вызывает стресс. Вы не можете принимать решения 24/7. Ваш мозг нуждается в отдыхе, и вы также должны сосредоточиться на важных вещах. Вот почему эти люди не решаются на такие незначительные вопросы.

Вот почему вы, как разработчик, не должны тратить свое время на поиск правильного порядка параметров (например, порядка ввода, вывода параметров) или правильного способа именования классов и т. д. Конечно, вы не должны просто писать случайные код, точно так же, как Обама не появится в паршивых джинсах, когда он посещает Букингемский дворец. Нет, вы должны писать чистый код в определенном стиле. Дело в том, что вам не придется принимать микрорешения о стиле именования, стиле отступов, потому что другие уже приняли это решение за вас. Следовательно, вы можете и должны сосредоточить свою энергию, свою решающую силу на дизайне, структурах данных и алгоритмах.

Резюме

Хорошие стандарты кодирования выгодны для всех заинтересованных сторон, даже если они довольно предвзяты. Они оптимизированы для читателя, а не для писателя. Как вы видели, есть причина. Код читается гораздо чаще, чем пишется. Хотя отсутствие стандартов может сделать ваш код нечитаемым, часть «кода, написанного с использованием последовательных правил, легче понять и усвоить другим рецензентам, что повышает эффективность процесса обнаружения дефектов» [2].

И не забывайте, что «лучший способ стать посредственным — через крошечные компромиссы» [3]. Не торопитесь и проверьте чистый и непротиворечивый код, которым вы гордитесь.

Ссылки

[1] Х. Абельсон и Г. Сассман: Структура и интерпретация компьютерных программ (1979, MIT Press).

[2] Википедия: Соглашения о кодировании https://en.wikipedia.org/wiki/Coding_conventions

[3] Сет Годин: Повышение среднего (13 июня 2016 г.) http://sethgodin.typepad.com/seths_blog/2016/06/raising-the-average.html