«//…» комментарии в конце блока кода после} - хорошо или плохо? [закрыто]

18

Я часто видел такие комментарии:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

а иногда даже до

if (condition) {
   ...
} // if (condition)

Я никогда не понимал эту практику и, следовательно, никогда не применял ее. Если ваш код настолько длинный, что вам нужно знать, что это за окончание }, то, возможно, вам стоит подумать о том, чтобы разделить его на отдельные функции. Кроме того, большинство инструментов разработчиков могут перейти к соответствующей скобке. И, наконец, последнее для меня - явное нарушение принципа СУХОЙ; если вы измените условие, вам также нужно помнить, чтобы изменить комментарий (иначе он может стать беспорядочным для сопровождающего или даже для вас).

Так почему люди используют это? Должны ли мы использовать это, или это плохая практика?

gablin
источник
В PHP я использую альтернативный синтаксис для структур управленияif(condition): ... else: ... endif;
systemovich
@ Джеффри ван Вик - правда? Я никогда не видел, чтобы кто-нибудь использовал их за пределами шаблонов. Они крайне нестандартные, но, наверное, каждому свое.
Крейг,
4
@Craige: Любая языковая конструкция, изначально поддерживаемая PHP, не является «крайне нестандартной» - интерпретатор PHP определяет, что такое «стандарт».
Билли ONEAL
Ада имеет специфические маркера для конца большинства конструкций: if ... then ... end if; while ... loop ... end loop; procedure Foo is ... end Foo;. Я считаю, что это помогает удобочитаемости (и проверяется компилятором, а комментарии нет).
Кит Томпсон

Ответы:

32

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

Однако в языках шаблонов (таких как PHP) это может быть допустимо, поскольку у вас может быть большой блок HTML, который разделяет начало и конец условия или структуры цикла.

Мэтт Эллен
источник
5
Абсолютно верный пункт для PHP, если вы используете PHP, смешанный с Html. 1 очко для Гриффиндора.
3
Даже с PHP в качестве языка шаблонов, смешанного с HTML, вы все равно можете делать отступы. Вы также не должны использовать фигурные скобки при использовании PHP в качестве языка шаблонов, а использовать конструкции while(): endwhile;and и foreach(): endforeach;т. Д.
Htbaa
9
Я действительно не понимаю, почему вы не должны рефакторинг PHP. Возможно, на другом языке.
Том Хотин - tackline
@Htbaa: я не могу поверить, что я использовал PHP все это время и не знал о них. Благодарность! Что касается отступов, я предпочитаю оставить условный HTML с отступом таким же, как и на остальной части страницы, а не в соответствии с PHP, который его создает.
Мэтт Эллен
3
@ Том: Я смеялся, но чувствую себя виноватым. : P
17

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

стихарь
источник
15

Это ужасная практика, устарелая многими факторами.

  • Большинство современных IDE выделяют соответствующую фигурную скобку, когда каретка находится на любом символе.
  • Если вы правильно программируете, вы редко найдете место, где ваш метод превышает 10 строк.

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

Настоятельно рекомендуем не использовать это.


источник
4
У меня есть коллега (Java-разработчик), который делает это. За исключением случаев, когда // for и // если он использует // rof и // fi. Это сводит меня с ума, и он делает это везде.
Джей
Да, я настаивал на этом. AAAAAGHHHHH.
Рог
2
Это на самом деле не имеет ничего общего с Java или Java-программистами, и это не является обычным или де-факто стандартным делом при программировании на Java.
Jesper
1
+1000 за "это ужасная практика".
scunliffe
6

Код читается в 10 раз больше, чем написано.

Если это облегчает чтение, сделайте это.

Я также предложил бы всем, кто делает это, что они должны посмотреть на некоторые другие способы сделать вещи проще для чтения. Методы рефакторинга, скобки на разных строках и т. Д., О которых упоминали другие люди, хороши. Разделение вещей на различные функции, методы или классы так, чтобы код самокомментировал, также хорошо. Существуют также способы устранения большинства «если» и помещения «в» циклов в очевидные места, тем самым устраняя необходимость во всем этом.

Но иногда люди учатся. Если это то, что они делают, это действительно делает код более читабельным, поощряйте его, а затем поощряйте и некоторые другие практики. Люди, которые учатся, заслуживают и получат пользу от поощрения, независимо от того, как они начинают. Сказать «Это плохо» не так полезно, как сказать «Это лучше».

Lunivore
источник
6
Это является плохим. Даже учебники для начинающих не делают этого злодеяния. «Код читается в 10 раз больше, чем написано» ... еще одна причина, чтобы не тратить время читателя на этот код.
Томас Эдинг
@trinithis Что если у вас есть 20-регистр оператора? Иногда вам нужно поддерживать 20 различных вариантов, и лучше собрать их в одном месте, чем «преобразовать» в какую-то многоуровневую схему принятия решений.
Quant_Dev
Я считаю, что это кодеры, которые недооценивают сверстников :), что другие не настолько умны, чтобы читать код, если только. В целом, я против этой практики, но хорошо, если кто-то делает это, потому что есть джунгли, которые делают его едва читаемым. Я не делаю этого в любом случае!
WinW
1
@trinithis Речь идет не о том, плохо это или нет, а об эффективных способах помочь людям стать лучше, чтобы они росли через это. Быть эффективным> быть правым. Это также очень разумная вещь, если, скажем, вы рефакторинге унаследованного кода, который еще больше беспорядок. Иногда плохие вещи могут сделать лучшие промежуточные шаги и привести к чему-то еще лучше.
Лунивор
1
@trinithis Извините, я не могу понять, что вы имеете в виду, когда все в одной строке. Я думаю, что упомянул, что есть и другие способы рефакторинга кода, которые разработчики могут сделать это.
Лунивор
4

У меня есть большая (C ++) кодовая база, полная такого рода вещей:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

Для чего-то такого маленького, я бы сказал, что это выходит за рамки «запаха кода» в «вонь кода». Особенно в IDE, где я могу сопоставить закрывающую скобку с нажатием клавиши, чтобы найти открывающую скобку. Учитывая более длинный метод, я все же возьму скобку, совпадающую с комментарием терминала. Такие комментарии отвлекают меня, и я склонен думать о них как о шуме.

PSU
источник
Хм, наверное, я не получаю некоторые форматирования на этом сайте; каждая скобка должна быть на отдельной строке, как и тело метода.
БП
В C ++ я часто буду открывать анонимное пространство имен вверху для скрытых вещей реализации. Затем в какой-то момент я закрываю эту фигурную скобку, и полезно знать, что означает эта фигурная скобка.
CashCow
4

В C ++ есть две задержки, которые по-прежнему полезны, и совет «разделить ваш код» не обязательно должен соблюдаться:

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

  2. Для пар #ifdef / #endif. Иногда там много кода для условной компиляции, он может стать неприятным со вложением, и редактор, который мы часто используем вручную, «услужливо» устраняет отступы, поэтому комментарии полезны во время быстрого обзора.

Йорис Тиммерманс
источник
+1 за комментарий пространства имен и причины. Это единственный раз, когда я делаю это и по той же причине
JohnB
+ длинные операторы переключения.
Quant_Dev
1

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

Если это просто говорит // IF Statement. Тогда вы должны удивиться, почему это там, во-первых.

TeaDrinkingGeek
источник
Я согласен, похоже, что строка закомментирована, а не старая школа//endif
StuperUser
1

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

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

Дойная корова
источник
1

Это в значительной степени пережиток прежних времен работы с терминальными окнами 80x24, особенно если вы использовали оконный редактор, такой как EVE. Даже сейчас я выполняю большую часть своей работы в терминальном сеансе, используя vim, и я могу разделить сеанс на три или четыре субокна, так что я могу реально просматривать только несколько строк одновременно.

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

Джон Боде
источник
0

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

Стейн
источник
эээ, объясни внизу пожалуйста. Я не просто придумал этот ответ, он проистекает из реального жизненного опыта: мой коллега, который сидит на пару футов рядом со мной, программировал более 10 таких ушей и не знал, почему это неправильно, пока я не объяснил ему ,
Стийн
Возможно, это использовалось в каком-то учебнике, так что группа людей вышла из колледжа, используя его? Это может иметь место во вступительном тексте. Также допустимо в препроцессоре, особенно в # ifdef / endif include guard
Martin Beckett