А в ваших разработках тоже не принято ставить комментарии?

[gl00mie]

Цитата:

Сообщение от mazzy

давным давно разработчики аксапты из даамгаарда исповедовали принцип самокомментирующегося кода (см. книги фаулера про рефакторинг) - это когда названия переменных/методов раскрывают суть выполняемых действий, а длина каждого метода невелика и выполняемые действия очевидны. но в ходе развития, из-за того, что надо обеспечивать совместимость и на уровне названий методов, принцип самодокументирующегося кода не удалось выдержать. сейчас есть классы и методы, названия которых не соответствуют тем действиям, которые реально выполняются. сейчас есть методы-портянки на мамндацать страниц (например, широко известный в узких кругах метод SettleNow).

Ой, неужели сопоставление было написано уже после того, как Дамгаард продался Навижену? Свежо предание, да верится с трудом. А прайс-листы, где значениями перечислений, означающих тип скидки, жонглируют как целыми числами, не применяя разве что побитовые операции, тоже написана отступниками от идей Фаулера из Навижен? А чудо-класс LedgerJournalEngine, который почему-то сделан сугубо клиентским, и в котором понапихана логика из дюжены различных типов журналов (if (journalType == такой-то) идем сюда, иначе вот сюда), вместо того, чтобы нормально параметризировать его логику и вынести методы-параметры в наследники, тоже придумали в Нивижен? А, может, он вообще родом из Майкрософта, где теперь программисты, движимые чувством вины и стыда, пытаются искупить вину обилием комментариев?..

Цитата:

Сообщение от Андре

Комментарий в коде нужен тогда, когда без него назначение кода не очевидно и не прозрачно. Кода, назначение которого не очевидно, следует избегать и комментарий здесь не лучшее, а наверное, и самое худшее решение.

Это мы сейчас про что говорим, про курсовую работу по информатике или про ERP-систему? Оно, конечно, здорово писать такой код, где имена говорят сами за себя, а методы содержат лишь дюжину-другую строк, но если модифицировать код системы не за счет бесконечных условных ветвлений в одних и тех же методах, а за счет использования ООП, то зачастую получаются классы-наследники, где перекрыты отдельные методы, обычно параметрические, или до/после вызова super() есть какой-то кусочек кода. Так вот, если не помнить наизусть, как работает родительский класс (а у меня лично иерархии наследования достигают подчас 4-х уровней, считая после RunBaseBatch), то код становится ну совсем непрозрачным, а предположения, в нем используемые, - совсем неочевидными. И в такой ситуации комментарий вида "эта переменная уже инициализирована там-то" спустя полгода-год позволяют намного быстрее разобраться в собственном же коде, не говоря даже про чужой.