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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

[Андре]

Цитата:

Ой, неужели сопоставление было написано уже после того, как Дамгаард продался Навижену?

Так о том и речь, что этот метод рефакторить нужно, а не комментировать.

Цитата:

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

А при чем тут комментарии. Согласен, что наследование не лучшая часть ООП, хотя бы потому, что оно позволяет нарушить принцип Лисков. Есть куча других способов повторного использования кода, которые на страдают увеличением кол-ва зависимостей между классами.

Цитата:

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

4 уровня наследвания после RunBaseBatch говорят о том, что надо задуматься и, может быть, пересмотреть иерархию объектов. Вы сами об этом и говорите, когда пишете, что код становится непрозрачным. Только вы предлагаете расставить комментарии, а я считаю это полумерой и предлагаю рефакторинг.

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

Пойду даже дальше и признаюсь, что я считаю нецелесообразным даже помечать модифицированный код в стиле

<--   
-- >

В большой консалтинговой конторе с большой историей проектов и большим количеством программистов таких бессодержательных комментариев в коде становится больше, чем самого кода. Особенно это относится к клиническим случаям, когда старый код не удаляется, а комментируется.

Для решения подобных задач предназначены cvs - системы и, если я ничего не пропустил, со своей задачей они пока справляются.

[mazzy]

Цитата:

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

Ой, неужели сопоставление было написано уже после того, как Дамгаард продался Навижену?

Метод был написан давно.
но таким страшным он стал не сразу.

[petr]

Цитата:

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

Метод был написан давно.
но таким страшным он стал не сразу.

В пятерке этот метод переписали (спасибо Микрософту) и он стал вполне красивым, коротким и относительно (того что было раньше) читабельным.

[Raven Melancholic]

Цитата:

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

В пятерке этот метод переписали (спасибо Микрософту) и он стал вполне красивым, коротким и относительно (того что было раньше) читабельным.

Это уже хорошая новость
Обычно этот метод когда требуется модификация, приходится изучать чуть ли не с нуля, несмотря на то, что я там уже наставил своих комментариев. Как раз случай, когда из-за ошибок дизайна комментарии слабо помогают.
А подход к комментариям у меня еще со времен изучения Дейкстры не изменился:

• Комментируется назначение метода (ну с учетом изменений, произошедших с тех пор и классов, форм и т.п.).
• Комментируются параметры методов (если не получается дать им "говорящие" имена)
• Комментируются места, которые потенциально опасны (к примеру, работающие с только с определенной версией того же Excel).
• Комментируются модификации (хотя тут согласен с Андре, что системы управления версиями с этой задачей справляются как нужно, но добавлю, что в тех случаях, когда код полностью контролируется самими, если он отчуждается, то приходится выбирать). Если же разных модификаций накапливается достаточно много, то чтобы не засорять код начинаем работать уже не с комментариями, а преобразовываем код.

В общем как-то так сложилось, что в нашей команде такой подход прижился и устраивает всех членов команды.
PS: естественно, не Дейкстры, а Кнута. Дейкстра это был мой кошмар при сдаче зачета по алгоритмам.