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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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