Речь о том, что ваш код должен быть понятен другому программисту с ходу, без скрежетания его мозга
Если ваш код нуждается в подробном комментировании - то это плохой код.
В больших коллективах при создании сложных проектов есть правило -
пиши проще.
Сервер для многопользовательской игры?
Я работал с огромным проектом на PHP (один из полусотни разработчиков в компании), и не представляю его даже на экосистемах Python или Ruby. А писать такое на Node.js или Go - это просто самоубийство.
Кстати, запрещались любые оптимизации кода, которые шли во вред читаемости ;)
Пусть даже менее оптимизированнее, но проще, яснее, понятнее. Это в конечном итоге окупается, когда один программист помогает другому, когда один программист заменяет другого, когда один программист проверяет другого. В конце концов, даже тогда, когда один и тот же программист
правит свой собственный код, но не выспался или устал или болеет или в плохом настроении.
Однако совсем без комментирования (например, экспорируемых/публичных элементов) тоже нельзя.
Имхо, нормальным является пояснение работы логики модуля для использования его со стороны (публичный интерфейс, публичное API). Внутри модуля нужно пояснять лишь изредка, лишь неочевидные моменты. Таких моментов должно быть минимум.
Форматирование обеспечивает привыкание глаза и легкость чтения. Поэтому в крупных конторах даже есть единые правила форматирования когда - когда все обязаны писать одинаково. Это поднимает производительность труда программистов при выполнении code review чужого кода и при поиске какой либо необходимой информации в чужом коде.
Это настолько важно, что в свежих языках (например, в Go) определенное форматирование кода является общеязыковым стандартом.
Простой
Простой
Простой
