Подтвердить что ты не робот

Пробел между символами комментария строки и началом фактического комментария

Я понимаю, что это правило может отличаться от одного стандарта кодирования компании другому, но в целом предпочтительнее?

  • С пробелом после комментария строки:

    int foo = Bar(quux + 1); // compensate for quux being off by 1

foo = Bar(quux + 1) # compensate for quux being off by 1

  • После комментария строки нет пробела:

    int foo = Bar(quux + 1); //compensate for quux being off by 1

foo = Bar(quux + 1) #compensate for quux being off by 1

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

Звучит так далеко, что у всех есть анекдотические доказательства того, что использование пробела является предпочтительным. Может ли кто-нибудь указать мне на какие-то официальные или опубликованные стандарты кодирования, которые напрямую касаются проблемы форматирования комментариев и следует ли использовать пробел?
4b9b3361

ОТВЕТЫ

Ответ 1

Руководство по официальному стилю Python, PEP 8, очень ясно говорит об этой проблеме:

Каждая строка блока     комментарий начинается С# и одного пробела (если он не отстутнут текст     внутри комментария).

и

Инлайн     комментарии должны быть разделены по крайней мере двумя пробелами из утверждения.     Они должны начинаться С# и одного пробела.

Это подтверждает все анонимные доказательства, но я думаю, что это первый ответ, который цитирует "некоторые официальные или другие опубликованные стандарты кодирования" по запросу; -).

Ответ 2

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

Ответ 3

За последние 24 года я профессионально разработал и поддерживал код в C, С++, Pascal, BASIC, Java, Perl, Objective C, Bourne shell, bash, csh, tcsh и сборке для 68K, PowerPC и x86. За это время я заметил несколько вещей...

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

  • Я не могу вспомнить, когда-либо видел комментарии в примере кода в профессиональной книге или руководстве без пробела.

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

  • Я никогда не видел официального стиля кодирования компании, который говорит людям опустить ведущее пространство в комментариях.

Итак, в целом, я бы сказал, что подавляющее доказательство состоит в том, что пространство после комментария строки предпочтительнее.

Ответ 4

Ну, я нашел стандарт (согласно Википедии) для комментирования на Java. Предполагается, что это "соответствует стандартам Sun Microsystems Javadoc":

/**
 * Registers the text to display in a tool tip.   The text
 * displays when the cursor lingers over the component.
 * @param text  the string to display.  If the text is null, 
 *              the tool tip is turned off for this component.
 */

Итак, я начинаю думать, что стандарт - это пространство. Кроме того, все остальные примеры имеют пробел.

Ответ 5

Я просто наткнулся на правило StyleCop SA1005, в котором говорится:

Нарушение этого правила происходит, когда однострочный комментарий не начинается с одним пространством. Например:

private void Method1()
{
  //A single-line comment.
  //   A single-line comment.
}

Комментарии должны начинаться с одного пробела после ведущих косых черт:

private void Method1()
{
  // A single-line comment.
  // A single-line comment.
}

Так как StyleCop так или иначе является продуктом Microsoft, я бы сказал, что это соответствует официальному стандарту кодирования в отношении пробелов в комментариях строки.

Ответ 6

В основном я избегаю комментариев в конце строки кода, потому что тогда комментарии висят от конца и не так легко анализировать при сканировании. Однако, когда у меня есть веская причина, мне нравится использовать два пространства для разделения кода и комментариев (затем одно место после маркера комментария). Это просто облегчает глаза...

Рассмотрим:

    int top;  // Index of the top of the stack.

против

    int top; // Index of the top of the stack.

Субъективно кажется, что два пространства просто облегчают разделение кода, а что нет.

Ответ 8

Руководство по стилю Google Java Style Форматирование требует помещения пространства с обеих сторон комментария:

4.6.2 Горизонтальные пробелы

Помимо того, где требуется язык или другие правила стиля, и кроме литералов, комментариев и Javadoc, одно место ASCII также появляется только в следующих местах.

...

  1. С обеих сторон двойной косой черты (//), которая начинает комментарий конца строки. Здесь допускается несколько пробелов, но не требуется.