Комментарий кода: Вы помещаете свои комментарии к коду на Интерфейсы или на Реальные классы или обоих? [дубликат]
Другой сам проблема закрывающего тэга для IE является элементом заголовка. Когда IE (просто попробовал его в IE7) видит это, это представляет пользователя пустая страница. Однако Вы "просматриваете источник", и все там.
<title/>
я первоначально видел это когда мой XSLT, сгенерированный сам закрывающий тэг.
9 ответов
Я бы прокомментировал оба.
По интерфейсам я бы прокомментировал намерение, стоящее за элементами интерфейса и их использованием.
По реализациям я бы прокомментировал причины конкретной реализации. .
Я обычно использую их на обоих, однако они не говорят одно и то же. Комментарий интерфейса должен описывать абстрактную цель этого метода / интерфейса. В то время как конкретный комментарий будет говорить об особенностях реализации метода / класса в контексте назначения интерфейса.
Я вставляю их в оба, но мне больно их синхронизировать, в случае сомнений я помещаю их только в интерфейс.
Я делаю это, потому что мне нравится всплывающая подсказка при использовании код, который почти всегда должен использовать интерфейс ...
Your example code doesn't use explicit interface implementation. The client of your code is going to need both since s/he can invoke the method either through a class object or interface reference. With explicit interface implementation you can omit the class method comment since the client can never see it. This is assuming you are using XML documentation to generate IntelliSense info.
И то, и другое, но я бы хотел, чтобы была встроенная функция для их синхронизации
A tag
Я вообще их не использую. Вместо этого я обязательно структурирую код и называю все методы и переменные так, чтобы было очевидно, что они делают, без комментариев. Проблема с комментариями в том, что они не компилируются, не выполняются и не проверяются вашими модульными тестами, поэтому практически невозможно синхронизировать их с кодом.
Только для интерфейсов. Потому что в этом случае мне не нужно их синхронизировать. Моя IDE помогает мне видеть комментарии к интерфейсу в конкретных классах. И генератор документов api делает то же самое.
Ideally, only the interface needs to be documented, since it defines the contract that every concrete implementation needs to fulfill.