Learn JavaScript #12. Качество кода.
В этой главе объясняются подходы к написанию кода, которые мы будем использовать в дальнейшем при разработке.
Логирование
Чтобы вывести что-то на консоль из нашего кода существует функция console.log.
Например, это выводит в консоль значения от 0 до 4:
// чтобы увидеть результат, сначала откройте консоль
for (let i = 0; i < 5; i++) {
console.log('value', i);
}Если правильно выстроить логирование в приложении, то можно и без отладчика разобраться, что происходит в коде.
Советы по стилю кода
Код должен быть максимально читаемым и понятным.
Это и есть искусство программирования - взять сложную задачу и написать такой код для её решения, который и правильно работает, и легко читается. Для этого нужен хороший стиль написания кода.
Синтаксис
Шпаргалка с правилами синтаксиса:
Руководства по стилю кода
Руководство по стилю содержит общие правила о том, как писать код, например: какие кавычки использовать, сколько пробелов отступать, максимальную длину строки и так далее - в общем, множество мелочей.
Когда все участники команды используют одно и то же руководство по стилю, код выглядит одинаково, независимо от того, кто из команды его написал.
Некоторые популярные руководства:
- Google JavaScript Style Guide
- Airbnb JavaScript Style Guide (есть перевод)
- Idiomatic.JS (есть перевод)
- StandardJS
- (и ещё множество других)
Автоматизированные средства проверки
(линтеры)
Автоматизированные средства проверки, так называемые "линтеры" - это инструменты, которые могут автоматически проверять стиль вашего кода и вносить предложения по его улучшению.
Самое замечательное в них то, что проверка стиля может также найти программные ошибки, такие как опечатки в именах переменных или функций. Из-за этой особенности линтер рекомендуется, даже если вы не хотите придерживаться какого-то "стиля кода".
Вот некоторые известные инструменты для проверки:
- JSLint – проверяет код на соответствие стилю JSLint, в онлайн-интерфейсе вверху можно ввести код, а внизу – различные настройки проверки, чтобы попробовать её в действии.
- JSHint – больше проверок, чем в JSLint.
- ESLint – пожалуй, самый современный линтер.
Комментарии
Комментарии могут быть однострочными, начинающимися с //, и многострочными: /* .... */.
Обычно мы их используем, чтобы описать, как и почему работает код.
Хорошие комментарии
Итак, обычно "объясняющие" комментарии - это плохо. Но тогда какой комментарий считается хорошим?
Важно то, что написано. Но то, что не написано, может быть даже более важным, чтобы понимать происходящее. Почему задача решена именно этим способом? Код не даёт ответа.
Если есть несколько способов решить задачу, то почему вы выбрали именно этот? Особенно если ваш способ – не самый очевидный.
Без подобных комментариев возможна следующая ситуация:
- Вы (или ваш коллега) открываете написанный некоторое время назад код и видите, что в нём есть, что улучшить.
- Вы думаете: «Каким глупым я раньше был и насколько умнее стал сейчас», и переписываете его на «более правильный и оптимальный» вариант.
- …Желание переписать код – это хорошо. Но в процессе вы понимаете, что «оптимальное» решение на самом деле не такое уж и оптимальное. Вы даже смутно припоминаете, почему, так как в прошлый раз вы уже его пробовали. Вы возвращаетесь к правильному варианту, потратив время зря.
Комментарии, объясняющие решение, очень важны. Они помогают продолжать разработку в правильном направлении.
Если в коде есть какие-то тонкости и неочевидные вещи, его определённо нужно комментировать.
Итого
Комментарии – важный признак хорошего разработчика, причём как их наличие, так и отсутствие.
Хорошие комментарии позволяют нам поддерживать код, дают возможность вернуться к нему после перерыва и эффективнее его использовать.
- Общую архитектуру, вид «с высоты птичьего полёта».
- Использование функций.
- Неочевидные решения, важные детали.
- Которые объясняют, как работает код, и что он делает.
- Используйте их только в тех случаях, когда невозможно сделать настолько простой и самодокументированный код, что он не потребует комментариев