Какие правила именования переменных и компонентов используются

Что проверяют

Пишете ли вы код, который читается без автора, и знаете ли конвенции JavaScript, TypeScript и React, а не общие советы. Следом часто спрашивают, как команда эти правила закрепляет: договорённостью или линтером.

Как отвечать

Пройдитесь по уровням:

• переменные и функции: camelCase. Имя отвечает на вопрос «что это»: activeUsers, а не data или arr. Коллекция во множественном числе, элемент в единственном: users.map(user => ...);
• булевы значения: префиксы is, has, can, should, например isLoading, hasError;
• компоненты, классы, типы: PascalCase. Для React это требование, а не вкус: JSX с именем в нижнем регистре считается HTML-тегом, и <userCard /> не отрендерит ваш компонент;
• хуки: обязательно начинаются с use. На этом префиксе держатся правила хуков и проверки eslint-plugin-react-hooks;
• обработчики: пропс называют onSubmit, а функцию внутри компонента handleSubmit;
• константы: UPPER_SNAKE_CASE только для настоящих констант уровня модуля вроде MAX_FILE_SIZE, а не для любой const;
• CSS: БЭМ (card__title--active) или CSS Modules, где классы пишут в camelCase, чтобы обращаться как styles.cardTitle; CSS-переменные в kebab-case;
• файлы: компонент в файле с тем же именем (UserCard.tsx), остальное по договорённости проекта.

Закончите тем, как это закрепляется: правило @typescript-eslint/naming-convention, Prettier для форматирования, ревью. Правило, которое проверяет машина, не зависит от внимательности ревьюера.

Где спотыкаются

Советуют snake_case для переменных. В JavaScript это чужая конвенция, так пишут в Python; в JS она встречается разве что в полях, пришедших из API.

Предлагают венгерскую нотацию вроде btnSubmit или txtUsername. В типизированном коде тип и так виден, а префиксы только удлиняют имена.

Называют по типу или порядку, а не по смыслу: userArray, data2, handleClick1. При переходе на Set имя начинает врать, а цифры не объясняют, чем одна функция отличается от другой.