Comments 8
Спасибо за статью.
Ничего маргинального в понимании ненужности комментариев в Go нет. Роб Пайк много лет на своих лекциях повторяет: "Комментарий никогда не должен отвечать, "что?" делает код. Если вам приходится писать такой комментарий - код плох и его надо переписать. Комментарий может отвечать только на вопрос "почему?" т.е. иногда нужно указать причину того, что код делает именно это (совместимость с каким-то хитрым API или легаси, неочевидные особенности работы железа, хитрая оптимизация и т.д.)". Отсюда и вытекает упомянутый идеоматичный нейминг (e.g. namespace.New), код сам описывает что делает.
Абсолютно не согласен.
Это применимо только когда ты пишешь сам и для себя. Если продукт как минимум смотреть кто то еще будет то коментарии необходимы. А если это классический комерческий продукт, с командой разработки и поддержкой годами - лучше коментариями даже вообще очевидные веши покрыть, а "вещи требующие причины" и вовсе заанотировать развернуто.
Много раз встречал такой лютый пиздец, что диву даешся как так можно на этом языке то - а разработчку все понятно.
Еще круто, когда у каких-нибудь функций, которые могут возвращать разные ошибки (например, транзакция), есть комментарий, описывающий что вообще может пойти не так, или почему функция вернула именно эту ошибку и т.д.
у нас на работе гексагональная архитектура - нам нравится )
in-port - все входы в домен (то что может инициировать некий процесс в сервисе)
domain - тут лежит бизнес логика, которая опирается на out-port-interface. Замокав out-port-interface - можно покрыть тестами всю бизнес-логику
out-port - всякие репозитории, внешние апишки - в общем реализация out-port-interface
а еще у нас contract-first. Swagger мы пишем ручками, на его основе генерится сервер.. тут же его можно отдать фронту - он сгенерит клиента и stub - идет одновременная разработка.
Немного не так цитату Пайка перевели:
Gofmt's style is no one's favorite, -- Никому не нравится code style gofmt.
yet gofmt is everyone's favorite -- но всем нравится gofmt.
Цитата про то, что важен не конкретный стиль, а его унифицированность и единогласное применение. А то, что он не должен никому нравится, но должен нравится всем, это жижа какая-то.
5 способов писать эффективный код на Go: от названий переменных до архитектуры