5 правил для улучшения читаемости кода

Читаемость кода - это особенность вашего приложения (даже если ваши пользователи этого не видят)

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

TL;DR

Всем тем, кто ищет быстрые советы, но не все читают, прочтите версию TL; DR ниже:

1. Повторно используйте то, что будет использоваться более одного раза.
2. Читаемость и ремонтопригодность по сравнению с универсальным решением.
3. Делайте модули, классы или компоненты как можно меньше.
4. Имейте правила и рекомендации для вашего кода.
5. Кодируйте так, как будто вы в команде - даже в команде из одного человека.

1. Повторное использование того, что будет использоваться более одного раза

Большинство разработчиков знают, что D.R.Y. означает (Не повторяйся). СУХОЙ. может помочь вам предотвратить дублирование кода.

Зачем писать функцию снова и снова? Вы должны написать его один раз и повторно использовать в нескольких местах. Если вам нужно изменить этот код, вам нужно только посмотреть в одном месте, вместо того, чтобы копировать исправление ошибки в нескольких местах.

Но имейте в виду, что вы привнесете сложности с D.R.Y. потому что, в конце концов, вещи будут использоваться все чаще и чаще.

Важность написания тестов при повторном использовании частей кода станет совершенно очевидной, когда вы начнете изменять этот код.

2. Читаемость и удобство обслуживания по сравнению с универсальным решением

Возможность повторного использования, удобочитаемость и ремонтопригодность - друзья и враги друг друга одновременно. Когда вы начинаете применять D.R.Y. в свой код вы вносите сложность. Когда вы вводите сложность, степень удобочитаемости может снизиться.

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

Посредством итераций вы можете повторно использовать части приложения, сохраняя при этом удобство чтения и ремонтопригодность.

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

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

В некоторых случаях вам нужно универсальное решение, но эти решения по-прежнему должны быть удобочитаемыми и поддерживаемыми.

3. Сделайте модули, классы или компоненты как можно меньше

Создавая новые функции для приложения, вы, вероятно, тщательно их планируете.

Лучшие решения - это те, которые можно разделить на небольшие модули, классы или компоненты. Вам интересно, почему?

Небольшие фрагменты кода легче тестировать и поддерживать.

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

Большинство современных библиотек и фреймворков делятся на более мелкие строительные блоки, а не на один файл. Библиотеки и фреймворки JavaScript, такие как Angular, React и Vue, применяют концепцию компонентов. Не думаю, что они делают это случайно.

4. Автоматизируйте правила и рекомендации для своего кода.

Одна часть написания читаемого и поддерживаемого кода - это его архитектура. Другая часть - это стиль кода.

Думаю, многие из вас знакомы с обсуждением использования табуляции или пробелов для отступов. Нет, я не собираюсь продолжать это обсуждение. Что бы вы ни использовали в своей команде, убедитесь, что это понятно всем.

Лучшее решение - автоматизировать большинство этих правил и рекомендаций по стилю кода. Это интегрировано во многие IDE или их можно установить через плагины.

Самый простой вариант для разных языков и редакторов кода - editorconfig. Эти правила будут применяться при добавлении .editorconfig.

Вы можете установить множество настроек для своего проекта в эти файлы. Их можно установить глобально и для определенных языков. Например:

• Стиль отступа: табуляция или пробелы
• Тип котировки: одинарное или двойное
• максимальная длина
• Набор символов
• И более…

Это конфиг одного из моих проектов:

# Editor configuration, see https://editorconfig.org
root = true
[*]
charset = utf-8
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true
[*.ts]
quote_type = single
[*.md]
max_line_length = off
trim_trailing_whitespace = false

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

5. Кодируйте, как будто вы в команде - даже в команде из одного человека.

И последнее, но не менее важное: пишите, как будто вы в команде!

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

Но если вы пишете проект самостоятельно, очень заманчиво написать код, который понимаете только вы (например, писать нечеткие имена переменных, использовать имена переменных из 2–3 символов и т. Д.).

Попробуйте написать свой код, как будто вы в команде. Представьте, что ваш код настолько ясен, что кто-то другой может легко понять ваш код.

Вы можете легко проверить это, попросив друга или кого-нибудь из сообщества разработчиков через Twitter проверить читабельность вашего кода. Могу обещать, что вы получите обратную связь, о которой никогда не думали.

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

Вы должны знать, что существует очень тонкая грань между читаемым кодом и не очень читаемым кодом. Он основан на мнении человека. Не расстраивайтесь, если кто-то скажет вам, что ваш код не читается! Будьте благодарны за отзыв.

Заключение

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

Если вам есть что добавить по поводу улучшения читаемости кода, не стесняйтесь делиться своими мыслями в комментариях.

Вы хотите выучить JavaScript простым способом? Я работаю над набором проектов, чтобы научить вас JavaScript без особых трудностей, чтобы вы могли создавать собственные интерактивные компоненты пользовательского интерфейса 👍

Подробнее