Как мы знаем из главы Структура кода, комментарии могут быть однострочными, начинающимися с //, и многострочными: /* ... */.
Обычно мы их используем, чтобы описать, как и почему работает код.
На первый взгляд, в комментариях нет ничего сложного, но новички в программировании часто применяют их неправильно.
Плохие комментарии
Новички склонны использовать комментарии, чтобы объяснять, «что делает код». Например, так:
// Этот код делает это (...) и вот это (...)
// ...и кто знает, что ещё...
очень;
сложный;
код;Но в хорошем коде количество «объясняющих» комментариев должно быть минимальным. Серьёзно, код должен быть таким, чтобы его можно было понять без комментариев.
Про это есть хорошее правило: «Если код настолько запутанный, что требует комментариев, то, может быть, его стоит переделать?»
Рецепт: выносите код в функции
Иногда выгодно заменить часть кода функцией, например, в таком случае:
function showPrimes(n) {
nextPrime:
for (let i = 2; i < n; i++) {
// проверяем, является ли i простым числом
for (let j = 2; j < i; j++) {
if (i % j == 0) continue nextPrime;
}
alert(i);
}
}Лучший вариант – использовать отдельную функцию isPrime:
function showPrimes(n) {
for (let i = 2; i < n; i++) {
if (!isPrime(i)) continue;
alert(i);
}
}
function isPrime(n) {
for (let i = 2; i < n; i++) {
if (n % i == 0) return false;
}
return true;
}Теперь код легче понять. Функция сама становится комментарием. Такой код называется самодокументированным.
Рецепт: создавайте функции
И если мы имеем такой длинный кусок кода:
// здесь мы добавляем виски
for(let i = 0; i < 10; i++) {
let drop = getWhiskey();
smell(drop);
add(drop, glass);
}
// здесь мы добавляем сок
for(let t = 0; t < 3; t++) {
let tomato = getTomato();
examine(tomato);
let juice = press(tomato);
add(juice, glass);
}
// ...То будет лучше отрефакторить его с использованием функций:
addWhiskey(glass);
addJuice(glass);
function addWhiskey(container) {
for(let i = 0; i < 10; i++) {
let drop = getWhiskey();
//...
}
}
function addJuice(container) {
for(let t = 0; t < 3; t++) {
let tomato = getTomato();
//...
}
}Здесь комментарии тоже не нужны: функции сами говорят, что делают (если вы понимаете английский язык). И ещё, структура кода лучше, когда он разделён на части. Понятно, что делает каждая функция, что она принимает и что возвращает.
В реальности мы не можем полностью избежать «объясняющих» комментариев. Существуют сложные алгоритмы. И есть хитрые уловки для оптимизации. Но в целом мы должны стараться писать простой и самодокументированный код.
Хорошие комментарии
Итак, обычно «объясняющие» комментарии – это плохо. Но тогда какой комментарий считается хорошим?
Описывайте архитектуру
Сделайте высокоуровневый обзор компонентов, того, как они взаимодействуют, каков поток управления в различных ситуациях… Если вкратце – обзор кода с высоты птичьего полёта. Существует специальный язык UML для создания диаграмм, разъясняющих архитектуру кода. Его определённо стоит изучить.
Документируйте параметры и использование функций
Есть специальный синтаксис JSDoc для документирования функций: использование, параметры, возвращаемое значение.
Например:
/**
* Возвращает x, возведённое в n-ную степень.
*
* @param {number} x Возводимое в степень число.
* @param {number} n Степень, должна быть натуральным числом.
* @return {number} x, возведённое в n-ную степень.
*/
function pow(x, n) {
...
}Подобные комментарии позволяют нам понимать назначение функции и правильно её использовать без необходимости заглядывать в код.
Кстати, многие редакторы, такие как WebStorm, прекрасно их распознают для того, чтобы выполнить автодополнение ввода и различные автоматические проверки кода.
Также существуют инструменты, например, JSDoc 3, которые умеют генерировать HTML-документацию из комментариев. Получить больше информации о JSDoc вы можете здесь: http://usejsdoc.org/.
Почему задача решена именно таким способом?
Важно то, что написано. Но то, что не написано, может быть даже более важным, чтобы понимать происходящее. Почему задача решена именно этим способом? Код не даёт ответа.
Если есть несколько способов решить задачу, то почему вы выбрали именно этот? Особенно если ваш способ – не самый очевидный.
Без подобных комментариев возможна следующая ситуация:
- Вы (или ваш коллега) открываете написанный некоторое время назад код и видите, что в нём есть, что улучшить.
- Вы думаете: «Каким глупым я раньше был и насколько умнее стал сейчас», и переписываете его на «более правильный и оптимальный» вариант.
- …Желание переписать код – это хорошо. Но в процессе вы понимаете, что «оптимальное» решение на самом деле не такое уж и оптимальное. Вы даже смутно припоминаете, почему, так как в прошлый раз вы уже его пробовали. Вы возвращаетесь к правильному варианту, потратив время зря.
Комментарии, объясняющие решение, очень важны. Они помогают продолжать разработку в правильном направлении.В коде есть какие-то тонкости? Где они используются?
Если в коде есть какие-то тонкости и неочевидные вещи, его определённо нужно комментировать.
Итого
Комментарии – важный признак хорошего разработчика, причём как их наличие, так и отсутствие.
Хорошие комментарии позволяют нам поддерживать код, дают возможность вернуться к нему после перерыва и эффективнее его использовать.
Комментируйте:
- Общую архитектуру, вид «с высоты птичьего полёта».
- Использование функций.
- Неочевидные решения, важные детали.
Избегайте комментариев:
- Которые объясняют, как работает код, и что он делает.
- Используйте их только в тех случаях, когда невозможно сделать настолько простой и самодокументированный код, что он не потребует комментариев.
Средства для генерации документации по коду, такие как JSDoc3, также используют комментарии: они их читают и генерируют HTML-документацию (или документацию в другом формате).