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

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

Определение удобочитаемости кода

Давайте уделим немного времени определению удобочитаемости, поскольку мы часто предполагаем, что все разработчики работают с одним и тем же определением. [1] определяет удобочитаемость кода как человеческое суждение о том, насколько легко понять текст. Есть много аспектов, таких как имена, длина подпрограмм, организация модулей и т. д., которые способствуют простоте понимания кода. Дело не только в пробелах и отступах, о которых мы обычно думаем, когда обсуждаем удобочитаемость. Кроме того, [2] контекстуализирует читаемость с точки зрения времени понимания, заявляя, что код должен быть написан так, чтобы свести к минимуму время, необходимое для его понимания кем-то другим. Понимание в этом контексте означает, что кто-то может эффективно находить дефекты, вносить изменения и/или расширять программу. Учитывая перцептивные и временные аспекты, мы можем определить удобочитаемость кода как искусство написания кода таким образом, чтобы свести к минимуму время, необходимое разработчику, чтобы понять этот код достаточно хорошо, чтобы он мог расширить или изменить его, не внося серьезных ошибок или неблагоприятно влияя на производительность.

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

Важность удобочитаемости

Читаемый код — это поддерживаемый код. Читабельность кода влияет на скорость и качество отладки программы или на то, насколько хорошо мы можем расширить ее новыми функциями. В то время как первоначальное внедрение программного обеспечения обычно привлекает наибольшее внимание заинтересованных сторон, на отладку, оптимизацию и расширение существующего кода приходится примерно 70% жизненного цикла программы [3] . Следовательно, в то время как код является средством написания инструкций для машины, программы должны быть написаны для того, чтобы люди их читали, и только случайно, чтобы машины могли выполнять их. [«4]

программы должны быть написаны для того, чтобы их читали люди, и лишь случайно для того, чтобы машины выполняли их.
- Abelson & Sussman

Разработчики часто тратят больше времени на чтение существующего кода, чем на написание нового. Нередко вы тратите более часа на чтение кода во время отладки только для того, чтобы обнаружить, что решение представляет собой быстрое изменение в 1 строку.

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

Причины нечитаемого кода

Предполагаемое влияние на производительность

Иногда мы предпочитаем писать менее читаемый код, хотя и не рационализируем его как таковой, потому что читаемый эквивалент привел бы к более длинной программе. Хотя, как правило, чем меньше кода мы пишем, тем лучше, но меньше кода не обязательно является эффективным кодом. Современные машины делают влияние на производительность (то есть накладные расходы функций, использование стека и т. д.) от написания большего количества кода незначительным, поэтому мы не должны преждевременно жертвовать читаемостью перед лицом предполагаемого влияния на производительность. «Преждевременная оптимизация — корень всех зол (или, по крайней мере, большей их части) в программировании». Удобочитаемость не противоречит эффективности, а простой для понимания код стоит больше пары миллисекунд по скорости, особенно когда производительность конечного пользователя не снижается.

Образование

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

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

Расписание требований

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

Никакого пряника для читаемого кода

Разработчиков обычно ценят за то, что они создают, и за количество вещей, которые они создают, а не за качество кода, используемого для создания программного обеспечения. Количество — удобный показатель для оценки качества разработчика. Сосредоточение внимания на удобочитаемости их кода очень субъективно и требует тщательного анализа, на который у нас не всегда есть время. Таким образом, в конечном итоге мы отмечаем разработчиков по продвижению по службе, предложениям работы и т. д. за то, что они создали, сколько они создали и как долго они работали, а не за качество их кода. [6]

Отсутствие поддержки со стороны заинтересованных сторон

Убедить заинтересованных лиц (как правило, нетехнических) в том, чтобы у них было время на рефакторинг и улучшение читабельности, — это трудная задача. С точки зрения продакт-менеджеров, продавцов и т. д., тратить время на переписывание кода, который не повлияет на функциональность и, следовательно, не представляет непосредственной ценности для клиента, — это не такое эффективное использование ресурсов, как устранение ошибок и создание новых функций. Это досадно, поскольку иногда мы сокращаем количество просмотров кода, заявляя, что проведем рефакторинг позже, когда на самом деле этот рефакторинг почти никогда не происходит.

Отсутствие долгосрочного мышления

Как разработчики, мы можем быть недальновидными и писать код, который имеет смысл в данный момент, но который будет трудно понять после того, как время отделит нас от кода. Когда вы создаете новые функции, вся номенклатура и жаргон этих функций всегда свежи в вашей памяти. Поэтому мы можем использовать непонятные сокращения или слишком умную логику, не способствующую быстрому пониманию. (А может быть, вы планируете сбежать с корабля, так что вам просто наплевать 😂) В общем, всегда спрашивайте себя: «Смогу ли я понять это за 4 недели?»

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