Рубріки: Front-end

Как писать чистый JavaScript-код: 13 стандартов от разработчиков из Google

Анастасия Бортничук

22.02.2022 16:24

В первой части материала на Highload я рассказала о популярных принципах в разработке, которых стоит придерживаться при написании кода, а также о том, как правильно называть переменные. Сегодня поговорим о стилизации JS-кода, таких инструментах как ESLint, Prettier, Code Spell Checker и SonarQube, а также о выстраивании архитектуры проекта. Начнем!

Стилизации JavaScript кода / Стандарты кодирования JavaScript

У разработчиков Google и Airbnb есть два самых популярных стилевых руководства по этой теме. Самыми интересными замечаниями и релевантными правилами я хочу поделиться с вами.

1Точки с запятыми

Каждое объявление должно заканчиваться точкой с запятой. Не полагайтесь на автоматическую вставку.

2Горизонтальное выравнивание — это плохо, но не запрещено

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

3Не используйте var

Объявляйте все локальные переменные с помощью const или let. Используйте const по дефолту, пока переменную не надо будет переназначить. Слово var не должно использоваться.

4Стрелочные функции предпочтительнее

Стрелочные функции дают краткий синтаксис и решают много сложностей с ним. Выбирайте стрелочные функции вместо слова function, особенно во вложенных функциях.

5Используйте шаблонные строки вместо их объединения

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

6Используйте одинарные кавычки, а не двойные

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

7Интервалы

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

8Не используйте пробелы в конце строк и в пустых строках

Строки обычно пишутся не длиннее 80 символов и не должны превышать 100 (считая каждую табуляцию за 4 пробела).

Это не жесткое правило, но длинные строки обычно указывают на нечитабельный или плохо организованный код.

А также:

унарные операторы (например, ++, --) не должны иметь пробелов после своих операндов;
перед , и ; не должно быть пробелов;

перед : после имени свойства в определении объекта не должно быть пробелов;
знаки ? и : в тернарном условном операторе должны иметь пробелы с обеих сторон;
в пустых конструкциях (например, {}, [], fn()) не должно быть заполняющих пробелов;
должна быть новая строка в конце каждого файла;
тело функции оформляется отступом в одну табуляцию.

9Равенство

Строгая проверка на равенство (===) должна использоваться вместо простой проверки (==). Единственное исключение — ситуация, когда осуществляется проверка на undefined или null путем проверки на равенство null.

10Комментарии

комментарии должны предшествовать коду, к которому относятся;

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

11Блоки и фигурные скобки

Блоки if, else, for, while, try всегда должны использовать фигурные скобки и располагаться на нескольких строках. Открывающая скобка должна быть в одной строке с определением функции, условием или началом цикла. Закрывающая скобка должна быть в строке, следующей за последним оператором блока.

12Многострочные предложения

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

13Цепочка вызовов методов

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

Инструменты: ESLint, Prettier, Code Spell Checker, SonarQube

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

ESLint

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

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

Многие из доступных правил в ESLint отключены, но их можно включить в файле конфигурации .eslintrc, который может быть глобальным или локальным для проекта. Одна из самых популярных настроек для линтера — Airbnb JavaScript Style. Она приводит код к более-менее единому стилю, умеет автоматически исправлять многие из найденных проблем и отлично интегрируется со многими инструментами разработки.

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

Prettier

Prettier — это форматтер. Он сканирует файлы по вопросам стиля и автоматически форматирует код. Таким образом единые правила соблюдаются для отступов, интервалов, запятых, одинарные vs. двойные кавычки. Рекомендуемым способом считается использование поддержки ESLint в eslint-plugin-prettier. Задача Prettier — заставить разработчика не думать о форматировании. В нем минимум настроек: поставил сам Prettier, поставил pre-commit-хук.

Чтобы работать с Prettier в Visual Studio Code, вам понадобится установить расширение. Для этого выполните поиск инструмента Prettier — Code Formatter в панели расширений VS Code. Вы можете превращать код с несогласованными отступами, скобками, разрывами строк и точками с запятой в хорошо отформатированный код. Чтобы автоматизировать этот процесс, вы можете выбрать в VS Code настройку, чтобы ваши файлы автоматически форматировались при сохранении. Это также гарантирует, что неформатированный код не попадет в систему контроля версий.

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

Code Spell Checker

Значительная часть ошибок, с которыми сталкиваются разработчики, связана с опечатками (или грамматическими ошибками) в именах переменных, функций и пакетов. Опечататься можно и в комментариях, описаниях, документации. Этот пакет подсвечивает ошибки в файле, учитывает код camelCase. Синие подчеркивания дают понять, какие слова необходимо исправить. Если вы хотите «размонтировать» слово как правильное написание, то можете щелкнуть правой кнопкой мыши, чтобы добавить его в пользовательский (глобальный) словарь или словарь папки (локальный).

SonarQube

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

SonarQube предоставляет следующие возможности:

поддерживает языки Java, C, C++, C#, Objective-C, Swift, PHP, JavaScript, Python и др.;
предоставляет отчеты о дублировании кода, соблюдении стандартов кодирования, покрытия кода модульными тестами, возможные ошибки в коде, плотность комментариев в коде, технический долг и др.;
сохраняет историю метрик и строит графики изменения этих метрик во времени;
обеспечивает полностью автоматизированный анализ: интегрируется с Maven, Ant, Gradle и распространенными системами непрерывной интеграции;
позволяет интегрироваться с такими IDE, как Visual Studio, IntelliJ IDEA и Eclipse с помощью плагина SonarLint;
обеспечивает интеграцию с внешними инструментами: JIRA, Mantis, LDAP, Fortify и т.д.

Расширять существующую функциональность вы можете с помощью сторонних плагинов.

Стандартный Quality Gate SonarQube использует следующие значения метрик для определения того, что код успешно прошел проверки:

0 новых багов;
0 новых уязвимостей;
коэффициент технического долга на новом коде <= 5%;
покрытие нового кода тестами не ниже 80%.

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

Команда Sonar определила семь смертных грехов разработчиков, увеличивающих технический долг:

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

Платформа SonarQube как раз и предназначена для того, чтобы помогать бороться с этими семью грехами.

Архитектура проекта, нейминг папок и файлов

Переходим к структуре проекта и именованию компонентов в React. Хотелось бы выделить такие преимущества структурированного проекта на React:

Членам команды не нужно думать о структуре проекта. Вместо этого они могут сосредоточиться на создании продукта.
Поскольку React имеет огромную экосистему, постоянно нужно думать: redux или mobx? HOC или render prop? react-motion или react-spring? Исключение одной из проблем — согласованная структура.
Общая структура проектов помогает новым участникам команды быстрее входить в курс дела. Короткий бриф — и уже можно догадаться, что в каждой папке и для чего нужны эти файлы.
Люди с меньшим опытом также могут создавать масштабируемые проекты.
Совместное и повторное использование кода.

Как оформлять компоненты React?

Имя файла компонента должно быть в CamelCase — TabSwitcher, а не tabSwitcher, tab-switcher. Называть другие типы файлов в такой нотации не нужно, т.к. CamelCase сигнализирует нам, что файл является компонентом React.
Избегайте экспорта по умолчанию. Это особый случай именованного экспорта (например, обязателен в Next.js), поэтому его необходимо обрабатывать особым образом. Это распространенная причина путаницы. Компонент можно импортировать так:import { TinyButton } from './shared/Button'
Все компоненты должны находиться в каталоге components. Храните каждый компонент в отдельном файле. Если вам нужен файл стилей, создайте папку и храните его там. Главное преимущество такого подхода в том, что компоненты не спрятаны где-то глубоко внутри. Они предназначены для повторного использования, поэтому их нужно хранить на виду.
Имена папок и компонентов должны совпадать. Таким образом, когда происходит поиск файлов, на выходе получаем не список файлов *.js, а актуальные файлы компонентов. Чтобы избежать необходимости импортировать такие компоненты: import { TinyButton } from './TinyButton/TinyButton' создайте файл index.js в той папке компонентов, которая экспортирует именованный компонент:

// components/TinyButton/index.js

export * from './TinyButton'

Перенесите маршрутизацию в каталог pages. Следуйте соглашению Next.js о структуре проекта, в котором логика маршрутизации хранится в каталоге pages. Каждая страница — это компонент React и имеет некоторое состояние. Компонент страницы использует другие компоненты для сборки страницы. Причина того, что логика маршрута не используется повторно в том, что компоненты страницы не могут быть reusable. Преимущество такого подхода в возможности быстро посмотреть доступные маршруты, центральное расположение всей логики маршрутизации, хранение компонентов страницы отдельно от других.

Атомарный дизайн — один из вариантов построения архитектуры проекта от Брэда Фроста

Поскольку искусство веб-дизайна продолжает развиваться, мы осознаем необходимость разработки продуманных систем дизайна, а не создания простых коллекций веб-страниц. В поисках вдохновения и параллелей автор все время возвращался к химии. Идея состоит в том, что вся материя (твердое тело, жидкость, газ, простая, сложная) состоит из атомов. Эти атомарные единицы соединяются вместе, образуя молекулы, которые, в свою очередь, объединяются в более сложные организмы, чтобы в конечном итоге создать всю материю в нашей Вселенной.

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

Атомарный дизайн — это методология создания дизайн-систем. В атомарном дизайне есть пять различных уровней:

Атомы — Молекулы — Организмы — Шаблоны — Страницы

И напоследок хочу процитировать автора в области разработки ПО Роберта Мартина и его характеристики чистого кода (уж очень они мне нравятся):

«Он должен быть элегантным: чистый код приятно читать. Чтение этого кода должно вызывать у вас улыбку, как мастерски сделанная музыкальная шкатулка или красивая машина».
«Чистый код сфокусирован: каждая функция, класс, модуль служат какой-то конкретной цели и не загрязняются окружающими деталями».
«Чистый код — это забота. Кто-то потратил время на то, чтобы сделать свой код простым и упорядоченным. Этот человек уделил должное внимание деталям. Он проявил заботу».

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.