Какие причины и обстоятельства следует предпочесть javadoc / phpdoc обычным комментариям?

Какие причины и обстоятельства следует предпочесть javadoc / phpdoc обычным комментариям? Я знаю, в чем разница в синтаксисе, но зачем использовать то или иное. Это в основном семантическое или есть другие причины, по которым я должен использовать одно вместо другого, и каковы они?

Я не совсем понимаю цель комментариев javadoc / phpdoc. Что не так со следующим блоком кода? ... /** - это просто способ заставить определенные комментарии окрашиваться в другой цвет в редакторе ... некоторые редакторы не различают (кажется, vanilla sublime этого не делает)?

/*
 * This block is wrapped in /** */ not /* */
 * Some documentation goes here
 * Below is copied from http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
 * @param  url  an absolute URL giving the base location of the image
 * @param  name the location of the image, relative to the url argument
 * @return      the image at the specified URL
 * @see         Image
 */ 

Другой вопрос ... есть ли причина, по которой я должен использовать и /** */, и /* */ в одном файле?

Последний вопрос ... Почему комментарии javadoc / phpdoc, по-видимому, связаны с классами ... но все же я видел, как они использовались как своего рода вводные комментарии к странице, что я изначально понимал?

на самом деле еще один ... рискуя ответить на свой вопрос, я задаюсь вопросом, действительно ли комментарии javadoc / phpdoc просто способ отличить комментарии, которые были написаны автоматически инструментом, и те, которые были написаны разработчиком?


person byronyasgur    schedule 27.03.2013    source источник


Ответы (3)


Вся причина, по которой люди используют Javadoc, - это согласованность и удобочитаемость - если вы знаете синтаксис, он позволяет легко взглянуть на чужой код (или наоборот) и понять смысл сразу. Вместо того, чтобы иметь что-то вроде:

// This method is used for counting sheep just before bed time
// It's really awesome, and takes the bed-time, and also age,
// And also number of sheep, in reverse order.

Что требует времени для обработки; гораздо приятнее увидеть:

/**
 * Count the number of sheep at bedtime
 *
 * @author Tom Walters 
 *
 * @param sheep   The number of sheep to count
 * @param age     The age of the person going to bed
 * @param bedTime The time of going to bed in 24hr format
 * @return The sheep were counted successfully
 */

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

Что касается /** - он помогает отличить этот стиль от таких вещей, как случайные комментарии и онлайн-комментарии, и является хорошим соглашением, помогающим Javadoc выделяться при просмотре кода.

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

person Tom Walters    schedule 27.03.2013
comment
Я бы сказал, что еще одна важная причина заключается в том, что вы можете создавать javadoc из комментариев. Это вроде как очевидно, но у меня почти создается впечатление, что ОП этого не знал ... - person Fredrik; 28.03.2013
comment
Отличный момент, все дело в том, чтобы облегчить жизнь программисту! - person Tom Walters; 28.03.2013
comment
Спасибо. Хороший ответ, но на мой вопрос он не отвечает. Я до сих пор не понимаю, почему в приведенном выше примере нельзя было использовать обычный блочный комментарий. Кстати, я понимаю разницу между javadoc и отдельными комментариями, просто не блокирую комментарии (кроме дополнительных * и другого цвета в некоторых редакторах) - person byronyasgur; 28.03.2013
comment
Подумайте об этом так: вы пишете javadoc для пользователей вашего кода - возможно, в общедоступном API, но вы бы использовали стандартные блочные комментарии для разработчиков вашего кода - других людей, которые напрямую его изменяют. Синтаксис /** был просто выбран для инструмента javadoc в качестве разделителя при синтаксическом анализе комментариев. - person Tom Walters; 28.03.2013
comment
Было бы верно сказать тогда, что на этот счет нет настоящего жесткого и быстрого правила, но что вы обычно используете комментарии типа документа для информации о типе обзора (находясь где-то между комментариями и файлом readme), а обычные комментарии блока, возможно, будут ограничены функция или что-то в этом роде ... если это так, то меня смущает то, что комментарии javadoc / phpdoc часто используются для классов ... это потому, что мы хотели бы фактически документировать классы, а не комментировать их ... извините я немного потерялся в семантике этого - person byronyasgur; 28.03.2013
comment
Несомненно, некоторые программисты будут подробно обсуждать эту тему, но в целом вы правы. Jdoc хорош для выражения умеренной сложности в виде обзорного типа методов класса и т. Д., Где блоки могут использоваться для особенно сложных функций. Комментарии обычно должны быть связаны с документированием вашего кода, когда смысл не в нескольких секундах размышлений. - person Tom Walters; 28.03.2013
comment
Спасибо ... только что понял что-то в своем ответе ... @param и @return ... имеют ли они какое-либо отношение к файлу, который не содержит классов, только функции? В каждом найденном мной руководстве в примере используется файл, содержащий классы? - person byronyasgur; 28.03.2013
comment
Они применяются повсеместно - класс или нет. Просто классы часто хорошо документированы, поскольку они представляют собой автономные коллекции кода, которые часто требуют обширной документации. - person Tom Walters; 28.03.2013
comment
ааа ... пенни падает ... спасибо ... Я как-то понял, что @param и @return можно использовать только с классами. Теперь все имеет смысл ... также я чувствую себя глупо, потому что я только что снова прочитал ответ Уби, и он действительно упомянул об этом - person byronyasgur; 28.03.2013
comment
@byronyasgur Вы знаете, что комментарии javadoc используются для создания HTML-документации об интерфейсах и классах? Это не просто комментарии к коду. Инструмент javadoc создает такие страницы, как эта: docs.oracle.com/javase/7/docs/api/java/lang/String.html Если вы хотите, чтобы что-то было в документации вашего класса, это должны быть комментарии javadoc. - person Fredrik; 28.03.2013
comment
@Fredrik ... вы говорите, что он должен или не должен использоваться для функций ... Я снова запутался - person byronyasgur; 28.03.2013
comment
Комментарии Javadoc используются для документирования классов, интерфейсов, перечислений и всего остального, что обычно попадает в javadoc. Вы должны использовать его для документирования цели, параметров, возвращаемых значений, исключений и других важных вещей, связанных с интерфейсом, который вы хотите задокументировать в своем javadoc (HTML-документация написанного вами кода). Большая разница по сравнению с обычными комментариями в том, что они документируют код и то, что он делает. Не имеет смысла помещать комментарий javadoc перед оператором. javadoc наплевать, это может быть простой комментарий. - person Fredrik; 28.03.2013
comment
@Fredrik не уверен, какие интерфейсы и перечисления, но можете ли вы конкретно прояснить, следует ли его использовать для функций. В противном случае я не понимаю, почему вы сделали свой первоначальный комментарий. - person byronyasgur; 28.03.2013
comment
Функции / методы являются частью общедоступного / защищенного / частного интерфейса класса, интерфейса или перечисления. Если вы хотите, чтобы метод был задокументирован с помощью инструмента javadoc, вы должны использовать комментарии javadoc, в противном случае это не имеет значения. Посмотрите на эту ссылку: docs.oracle.com/javase/7/docs/api/java/lang/ Это ВСЕ создано из данных, указанных в комментариях javadoc. Если бы комментарий javadoc был заменен обычным комментарием, вы бы увидели первую строку public String toUpperCase (Locale locale) и ничего более. - person Fredrik; 28.03.2013
comment
@Fredrik Нет, я просто хочу прояснить, могу ли я / не могу использовать javadoc / phpdoc с обычными функциями ... ничего общего с классами - person byronyasgur; 28.03.2013
comment
Вы можете, но в этом нет большего смысла, чем начинать комментарий с / ******************* (что, конечно, нормально). - person Fredrik; 28.03.2013

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

Форма /* */ содержит только комментарии к коду, как и //.

Некоторые IDE будут использовать информацию phpDoc, содержащуюся в /** */ блоках, чтобы показать вам некоторую подсказку. Кроме того, такие программы, как phpDocumentor, используют /** */ блоки для создания файлов документации.

person ulentini    schedule 27.03.2013

Просматривая все комментарии и обсуждения выше, похоже, у вас все еще есть вопросы об использовании комментариев Javadoc только к функциям. Ответ будет ДА, вы можете использовать комментарии javadoc к функциям, которые не обязательно должны быть в определении класса.

Зачем использовать комментарии javadoc вместо обычных? Основная причина заключается в использовании инструмента Javadoc, который создаст справочный документ локального API (html), в котором объясняется, как использовать ваши функции и какие типы возврата ожидать от этих функций (и методов класса). Без комментариев javadoc инструменту Javadoc нечего было бы помещать в сгенерированный документ API. В комментариях javadoc вы помещаете то, что будет отформатировано в файлы html для вашего собственного API. Инструмент javadoc видит / ** как специальный комментарий и читает это содержимое. Компилятор Java (или интерпретатор PHP) увидит / ** и подумает, что это / * игнорирует все до следующего * /, они рассматривают это как любой обычный комментарий.

Поэтому, если вы планируете иметь легкий для чтения ссылочный справочный документ с возможностью нажатия, комментарии javadoc абсолютно необходимы, в противном случае они не имеют значения. Однако использование Javadoc API в качестве справочника позволяет значительно сэкономить время, чтобы посмотреть, как работают ваши функции, без необходимости искать их в коде.

Иметь Javadoc API моих файлов - это здорово, если мне нужен кто-то еще, чтобы помочь в проекте. Гораздо проще щелкнуть гиперссылку в веб-браузере, чтобы увидеть объяснение функции, вместо того, чтобы искать файл, открывать файл, искать функцию, читать код и определять, что она делает.

Воспользуемся этим примером:

public int addSquares( int x, int y ) {
  int value = x*x + y*y;
  return value;
}

Само по себе вы должны прочитать, что эта функция принимает два целых числа, возводит их в квадрат и возвращает сумму обоих квадратов. если бы мы были в Javadoc, функция с:

/**
* Squares two numbers, and returns the sum of those squared numbers.
* @param x first value to square
* @param y second value to square
* @return value of x*x + y*y
*/

если вы запустили свой файл .java с помощью инструмента Javadoc, у вас будет файл html, который показывает:

int addSquares( int x, int y )
    Squares two numbers, and returns the sum of those squared numbers.

Это дает вам тип возвращаемого значения, параметры и краткое описание функции. Также addSquares будет гиперссылкой на более описательный раздел на той же HTML-странице, который будет выглядеть примерно так:

addSquares
public int addSquares (int x, int y)
Возводит два числа в квадрат и возвращает сумму этих квадратов чисел.

Параметры:
первое значение x преобразуется в квадрат
второе значение y преобразуется в квадрат

Возвращает:
значение x * x + y * y

Да, в этом примере очень просто читать код, но когда ваши функции / методы / классы становятся более сложными, гораздо быстрее использовать задокументированный справочный API, созданный с помощью комментариев Javadoc. Поэтому, если вы не планируете создавать справочную документацию по API, комментарии javadoc ничем не отличаются от обычных комментариев, за исключением того, что они имеют другой цвет в вашем редакторе.

person kralvarado    schedule 24.08.2013