Ответ
Да, но только «правильные» комментарии. Цель комментария — объяснить «почему» и «зачем», а не «что» делает код (это должно быть понятно из имён переменных, функций и структуры).
Хорошие комментарии (рекомендуется):
- Объяснение сложной бизнес-логики или алгоритма.
- Причина неочевидного решения (например, обход известной ошибки в библиотеке).
- TODO / FIXME — отметки для будущих улучшений.
- Javadoc / KDOC / и т.п. — документация публичного API.
Плохие комментарии (избегать):
- Дублирование кода:
x = 5; // присваиваем 5 переменной x - Устаревшие: комментарии, не соответствующие текущей логике.
- Излишне эмоциональные или неформальные.
Пример:
// ПЛОХО: комментарий избыточен
int delay = 3000; // задержка в 3 секунды
// ХОРОШО: комментарий объясняет причину выбора значения
// Таймаут установлен в 3 сек, согласно SLA сервиса X (отвечает за 99% запросов)
int requestTimeoutMs = 3000;
// ХОРОШО: комментарий объясняет неочевидную оптимизацию
// Используем IdentityHashMap, т.к. нам важно сравнение по ссылкам (==),
// а не по значению (.equals()), для учёта циклических зависимостей.
Map<Node, List<Node>> adjacencyMap = new IdentityHashMap<>();Пишите самодокументирующийся код, а комментариями поясняйте только нетривиальные решения.
Ответ 18+ 🔞
А, ну вот, опять про эти ваши комментарии, блядь! Слушай, давай я тебе как человек, который видел код, от которого глаза на лоб лезут, объясню, в чём тут соль.
Представь, ты открываешь файл, а там такое:
int a = 5; // присваиваем переменной a значение 5
int b = 10; // присваиваем переменной b значение 10
int c = a + b; // складываем a и b, результат кладём в cЁпта, да я и так вижу, что складываешь, мудила! Ты думаешь, я в арифметике не шарю? Это не комментарий, это оскорбление интеллекта, блядь! Такой код читать — это как слушать, как кто-то вслух читает инструкцию к микроволновке. Скука ебаная!
Вот в чём, сука, магия настоящего комментария: он должен отвечать на вопросы «ПОЧЕМУ?» и «ЗАЧЕМ?», а не на вопрос «ЧТО?». «Что» — должно быть видно из самого кода, если ты, конечно, не обозвал переменные x1, y2 и data.
Хороший комментарий — это как история за кадром. Вот смотри:
// ПЛОХО: ну ты понял, это пиздец, а не комментарий.
int delay = 3000; // задержка в 3 секунды
// ХОРОШО: а вот тут уже интересно. Почему именно 3 секунды? А потому что!
// Таймаут в 3 сек выбран не с потолка, а потому что сервис "ПлатеЖёпка"
// в 99% случаев отвечает за 2.5 сек. Даём ему немного форы, но не ждём вечность.
int paymentGatewayTimeoutMs = 3000;
// ХОРОШО: а это вообще высший пилотаж. Смотри, тут всё неочевидно.
// Используем IdentityHashMap вместо обычного HashMap, потому что
// узлы (Node) могут быть логически равны (.equals()), но это РАЗНЫЕ объекты в памяти.
// Нам критично сравнение именно по ссылкам (==), чтобы избежать
// еб*ни циклических зависимостей, которые сломают алгоритм обхода.
Map<Node, List<Node>> graphAdjacency = new IdentityHashMap<>();Видишь разницу? В первом случае — мозг вытекает. Во втором и третьем — ты сразу понимаешь причину решения. Может, через полгода придет другой чувак, посмотрит на IdentityHashMap и подумает: «Какой же пидорас тут накодил?». А потом прочтёт комментарий и скажет: «А, ну да, логично, мужик был не дурак».
Так что запомни, как «Отче наш»:
- Пиши про «ПОЧЕМУ»: объясняй хитрую бизнес-логику, алгоритмическую хуйню или причину костыля (типа «библиотека Y версии 2.1.3 гонит здесь левых газов, поэтому делаем так»).
- Пиши TODO/FIXME: это святое. «// TODO: переделать на нормальный кэш, когда команда Бэкенд-Ёпты перепишет API». Это не стыдно, это честно.
- Документируй публичное API: вот это вот Javadoc над функцией — обязательно. Чтобы тот, кто будет её вызывать, не гадал на кофейной гуще, что она там вернёт при
userId = null.
А всё остальное — говнокод. Самодокументирующийся код — это когда имена переменных и функций говорят сами за себя. calculateTotalPrice() и так понятно, что делает. Не надо над ней писать «// функция для расчёта общей цены». Это пиздец, ребята.
Короче, суть в том, чтобы твой код не был немым, как тот Герасим из рассказа, который только «Му-му» мычал. Пусть он объясняет свои мотивы, особенно когда делает что-то нестандартное. А очевидные вещи — и так очевидны, в рот меня чих-пых!