Комментарии XML: использовать или не использовать? - PullRequest
2 голосов
/ 19 января 2009

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

Спасибо!

Ответы [ 6 ]

5 голосов
/ 19 января 2009

XML-комментарии полезны для создания документации. Если код написан четко, вам не нужны комментарии, которые помогут вам понять код.

Однако комментарии к документации полезны для пользователя классов, поскольку они (должны) содержать описание функциональности класса или методов, а не описание кода.

1 голос
/ 02 июля 2011

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

Linker.Extract(IpoValidator validator, MeanDexIndicator Indicator)

Если он не понимает контекст метода, он не может понять его цель. Основная проблема, которую люди, кажется, имеют с комментариями, они не очень полезны. Это потому, что люди пишут плохие комментарии. Вы должны говорить о том, что происходит, а не о том, что происходит. Я вижу, что этот метод является методом извлечения, поэтому комментарии вроде:

 <Summary>Extracts The Fumble <\Summary>

Это пустая трата энергии. Лучше следующее:

 <Summary>
 The Fumble needs to be extracted before the bopper can be used. In order for 
 extraction to work a validator and indicator need to be provided. Once extracted 
 the bopper is available in the property Linker.Bopper. On fail this 
 method will raise the CrappedOutException.
 </Summary>

Видите разницу?

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

Что касается парня, который отказывается обновлять свои комментарии после изменения чего-либо. Обзоры кода должны это уловить. Лично я использую xml-комментарии о частных методах и поддерживаю два, но этот - личный выбор. На общедоступные методы и свойства? Я не является обязательным.

0 голосов
/ 19 января 2009

Нет ли тега аннотации, который функционально игнорируется, но может быть обработан некоторым XSLT для непосредственного превращения в документацию? Комментарии хороши (и я их использую), но я думаю, что значение тега аннотации и его непосредственное преобразование могут перевесить использование комментария в качестве документации. Таким образом, в общем, используйте теги аннотаций для документации, которая будет прочитана другими, используйте комментарии для заметок к себе или «за кулисами» (т. Е. «ИСПРАВИТЬ, ЭТО ПРЕЖДЕ, ЧЕМ МИР ВЫСТАЕТ!»)

0 голосов
/ 19 января 2009

Что касается внутреннего кода и комментариев, вот сообщение от Джеффри Палермо , которое я только что прочитал и с которым должен согласиться.

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

0 голосов
/ 19 января 2009

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

0 голосов
/ 19 января 2009

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

...