Чтобы по-настоящему понять удобочитаемость, нам нужно на мгновение отдохнуть от компьютерных наук и перейти к психологии.
Стиль кодирования - горячая тема. Разработчики повсюду спорят о табуляциях и пробелах, фигурных скобках на одной строке, ограничениях на длину строк и многом другом. Люди изобретают автоматический линтер, чтобы находить нарушения стиля и ломать сборки, как это сделали бы компиляторы. Но почему? Почему стиль кода должен нарушать сборку? Сегодня мы рассмотрим первые принципы удобочитаемости, чтобы понять, откуда взялись эти правила.
Познавательная нагрузка
Чтобы по-настоящему понять удобочитаемость, нам нужно на мгновение отдохнуть от компьютерных наук и заняться психологией. Каждый человек может одновременно держать в голове столько всего, что называется рабочей памятью. Когнитивная нагрузка относится к пространству, которое что-то занимает в рабочей памяти человека. Вы можете думать об этом как о кеше: когда он заполнится, что-то нужно очистить, чтобы добавить что-то новое.
Однако правила когнитивной нагрузки далеко не так просты, как структуры данных. Подумайте о телефонных номерах: какие из них легче запомнить?
Если вы похожи на меня, вы списываете числа в начале и конце как «слишком много информации». Посередине гораздо понятнее. Это потому, что каждое число имеет разную когнитивную нагрузку.
Ошибки и эффективность
Теперь, когда мы немного больше понимаем человеческую память, мы можем применить ее к работе над программным обеспечением. У каждой функции есть свои ошибки и крайние случаи, поэтому, чем больше разработчик может сразу уместить в своей голове, тем больше вероятность, что он обнаружит ошибки перед развертыванием.
Проблема поднимается еще больше, когда приходит время для проверки кода. Если я потрачу всю свою рабочую память только на чтение кода, я ни за что не смогу найти крайние случаи. Подумайте, что бы произошло, если бы вас попросили просмотреть минифицированный Javascript!
Благодаря этой связи у нас наконец-то появилось волшебное правило читаемости кода: Сведите к минимуму когнитивную нагрузку на ваш код.
Принципы стиля
Вот три простых правила касательно когнитивной нагрузки:
- Небольшие автономные фрагменты - это небольшая нагрузка. Номер телефона, состоящий из трех частей, легче запомнить, чем один длинный номер.
- Практика ведет к совершенству. Мозг со временем лучше запоминает повторяющиеся структуры, уменьшая их нагрузку.
- Предположения значительно экономят время. Полагаться на предположение означает почти полностью пропустить рабочую память.
Эти правила отражают основные принципы написания хорошего кода:
- Используйте функции, чтобы разделить вашу логику на легко читаемые разделы. Читателям нужно будет прочитать только название вашей функции, а не все.
- Сохраняйте единый стиль в отступах и скобках, чтобы другие могли не думать о пробелах и сосредоточиться на выполняемом коде.
- Создавайте свою кодовую базу, используя слои, чтобы другие могли делать предположения о структуре вашей функции и не исследовать ее.
Чем больше мы будем следовать этим правилам, тем ниже будет наша когнитивная нагрузка и тем меньше ошибок мы создадим. Если мы не будем следовать им, мы будем тратить все больше и больше времени на попытки разгадать уже написанный код, замедляя работу и вводя ошибки.
Правила хорошего и плохого стиля
Наконец, со всем нашим новым пониманием и принципами, мы можем разработать полезное руководство по стилю. Однако будьте осторожны: можно зайти слишком далеко.
Правило хорошего стиля напрямую влияет на способность понимать функциональность кода. Разработчики полагаются на отступы для определения функциональности, поэтому сюда входят правила скобок и отступов. Эти правила упрощают процесс понимания кода, применяя приведенные выше принципы.
Правило плохого стиля - это правило, требующее согласованности ради последовательности. Некоторые примеры - это правила, касающиеся последовательного подсчета пустых строк или завершающих пробелов. Эти правила могут вызывать ошибки в строках, в которых вообще нет кода, фактически добавляя когнитивную нагрузку на кодовую базу, не принося какой-либо (буквально) видимой пользы людям.
В подобных случаях важно помнить, что необязательно указывать правило для всего. Последовательность полезна, но ее нельзя применять, не задумываясь о ее цели. Добавляйте правила lint по одному, продумывая каждое из них: как это поможет другим читать код?
