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

Код должен читаться легко

Компьютер выполнит любую команду, даже если она выглядит как x = y + z * 42. Но человек, который будет читать ваш код — тимлид, ревьюер, коллега — должен понимать, что в нем происходит, желательно с первого взгляда, поэтому:

1. Названия переменных и функций — ваша первая линия коммуникации. Например, getUserData() говорит гораздо больше, чем gud(). Не сокращайте имена до абсурда, не используйте загадочные аббревиатуры, не прячьте смысл во «временных» и абсолютно неинформативных названиях вроде temp1 или data2. Чем понятнее имя — тем меньше вопросов.
2. Комментарии к коду нужны, если они отвечают на вопрос «почему». Например, комментарий «// отключили проверку, потому что API нестабильный» полезен, а комментарий «// проверка» — нет. Комментируйте неочевидный моменты, к примеру, нестандартные или временные решения.

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

Контролируйте структуру и оформление

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

1. Используйте отступы, пробелы, переносы строк. Они помогают ориентироваться и не превращают код в нечитабельный «кирпич» текста.
2. Разделяйте блоки по смыслу: логика, обработка ошибок, рендеринг — не в одной куче. В React-компонентах, например, удобно придерживаться порядка: сначала пропсы, потом вычисления, потом JSX.
3. Настройте инструменты для автоматического форматирования кода. Например, Prettier расставляет пробелы, переносы, кавычки, а ESLint подсказывает, где допущены ошибки или нарушен стиль.

Эти программы встроены в большинство редакторов кода и работают в фоновом режиме. Они помогают начинающим разработчикам делать код единообразным.

Не усложняйте, если можно проще

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

Если задачу можно решить просто — решайте просто. Не добавляйте лишние абстракции, не оборачивайте очевидное в три слоя логики. Например, если вы пишете useEffect(() => { fetchData(); }, [ ]), убедитесь, что это действительно нужно, а не просто «так делают все». Иногда проще вызвать функцию напрямую, если это не нарушает логику компонента.

Избегайте «магических чисел» — вместо if (score > 42) лучше написать if (score > MIN_PASSING_SCORE). Так сразу понятно, что значит число. А если значение изменится, вы поменяете его в одном месте, а не по всему коду.

Простота кода — это не примитивность, а ясность, которую ценят все разработчики.

Делайте код предсказуемым

Предсказуемый код ведет себя так, как от него ожидают. Если функция называется getUserInfo, она должна возвращать информацию о пользователе, а не, скажем, удалять его из базы. Название должно соответствовать действию, а действие — быть прозрачным. Чтобы сделать код предсказуемым:

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

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

Заботьтесь о тех, кто будет работать с проектом

Ваш код — часть общего проекта. Его постоянно будут менять, расширять. И чем понятнее он написан, тем проще это делать. Это хороший тон и маркер уважения к коллегам. Приведем несколько примеров:

• Если суть проекта не очевидна из названия, напишите в коротком README: что делает код, как его запустить, какие есть зависимости.
• Если часть логики временная, оставьте комментарий, вроде: «// временно отключено, вернем после фикса API». Если что-то требует доработки — напишите «TODO», чтобы не забыть и не оставить «висящие» куски.
• Не оставляйте заглушки без пояснений. Не пишите «потом разберусь» в коде. Лучше сразу обозначить, что требует внимания.

Заключение

Если вы только начинаете путь во Frontend-разработке, запомните главное правило: код читают чаще, чем пишут. И чем понятнее вы кодите, тем проще будет расти в профессии, проходить ревью и получать хорошие офферы. А чтобы освоить весь комплекс навыков и инструментов, необходимых для успешного старта и развития IT-карьеры, приходите на курс «Frontend-разработчик» в Айтилогию.