Я никогда не работал на работодателя, и у меня сформировался свой стиль писания кода. В частности, сложилась привычка писать стандартные комментарии. Не знаю как в других языках, а Delphi часто по коду без комментариев непонятно, что означает тот или другой end; (конец программной скобки). Например, в коде

if a=b then begin
...
end;

Я привык после end добавлять:

end; //a=b

Есть много других аналогичных примеров: для case, для for и для произвольных программных скобок

case a of
1:begin
...
end; //q
2:begin
...
2nd; //2
end; //case

for i:=0 to count-1 do begin
end; // next i

Насколько всё это актуально в других языках? И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода? Вроде затраты на написание лишнего слова очень невелики.
Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.

Здравствуйте, Khimik, Вы писали:

K>Насколько всё это актуально в других языках? И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода? Вроде затраты на написание лишнего слова очень невелики.
K>Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.

Последние годы везде где я работал использовались автоматическое форматирование: clang-format для C++,
rustfmt для Rust, gofmt для Go и т.д.
На мой взгляд это необходимый элемент для плодотворного "code review".
Ну и clang-format по умолчанию для "namespace foo {" добавляет "} // namespace foo" ,
если в объявлении "namespace" больше пары строчек. Но ни для чего более такая фишка не используется.
Предполагается наверное что весь остальной код: for, if, while, реализация функции
должны быть небольшими и такое форматирование не нужно.

>begin
>end
K>Насколько всё это актуально в других языках? И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода? Вроде затраты на написание лишнего слова очень невелики.
K>Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.
Новые VS сами и отступы расставляют, и такие комментарии рисуют изображением. Последуйте уже за создателем Delphi

Здравствуйте, Khimik, Вы писали:

K>Насколько всё это актуально в других языках?

Если конструкция вмещается на экран, это не нужно. Если не вмещается, значит надо её переписать, чтобы вмещалась.

Хорошие IDE умеют показывать соответствующую строчку. Например здесь у меня курсор стоит в конце метода, IDE сверху показала строчку, которой соответствует закрывающая скобка.

https://i.imgur.com/wjM0adE.png

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

Не думаю.

K>Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.

Так никто не пишет. Дело, конечно, твоё.

Здравствуйте, Khimik, Вы писали:

K>Насколько всё это актуально в других языках? И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода? Вроде затраты на написание лишнего слова очень невелики.
K>Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.

C++. Отступы в общем случае удобнее. clang-format приводин весь код к единому стилю в плане отступов.
Исключение — namespace, которые заканчиваются сильно дальше, их принято комментировать.
И препроцессор. Тут мне нравится MSVC STL подход:

#if __cplusplus >= 202002L 

...

#else // ^^^ C++20 ^^^ / vvv pre C++20 vvv

...

#endif // ^^^ pre C++20 ^^^

Здравствуйте, Alexander G, Вы писали:

AG>И препроцессор. Тут мне нравится MSVC STL подход:
AG>

AG>#if __cplusplus >= 202002L 

AG>...

AG>#else // ^^^ C++20 ^^^ / vvv pre C++20 vvv

AG>...

AG>#endif // ^^^ pre C++20 ^^^
AG>

И препроцессор так коментирую, и отступы делаю, и namespace/if/for/etc так заканчиваю. namespace — всегда помечаю, if/for/etc — только длинные. Не всегда имеет смысл всё сразу раскидывать по функциям, плюс, когда пишешь — не всегда понятно, что и как, и сначала пишешь простынёй, потом рефакторишь, раскидывая по функциям

Здравствуйте, Khimik, Вы писали:

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

Ничего стандартного в них нет. Это шум.

* Как гарантировать, что такой "стандартный" комментарий не рассинхронизировался со временем или даже в самом начале? Например, я уже нашёл рассинхрон прямо в примере: case a of 1:, но end; //q. Написать утилиту, выявляющую такие косяки? Написать дополнение для какого-либо из уже существующих инструментов? Бесконечно читать комментарии, которые и быть формальными по своему определению не должны?
* Как растёт количество строк в диффах? Как это может влиять практически на конфликты при слиянии разных версий?
* Можно ли считать, что чтение таких комментариев является отвлечением от чтения актуального кода?
* Сколько времени и усилий тратится на поиск и исправления несоответствий, например, при код-ревью?
* Что делать с Break и Continue? А с procedure, function и т.п.? А с "висячим" repeat или безымянным else?
* Почему такая неоднородность: //a=b, "бэйсиковизм" //next i и просто //case?

K>Насколько всё это актуально в других языках?

Кажется, нисколько. Для такого нужен редактор, позволяющий либо отображать навигационную цепочку с поддержкой операторов для элемента под курсором (или любая из вариаций, например, та, которую привёл в качестве примера vsb), либо позволяющая виртуально рендерить текст, ассоицированный с закрывающей/закрывающей скобкой, если нужно видеть всё и сразу.

K>И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода?

Оно того не стоит. Код сам по себе должен быть информативным и самодокументированным.

Здравствуйте, Khimik, Вы писали:

K>

K>end; //a=b
K>

Удобно для случаев, когда далеко искать парный элемент, или что-то в этом поиске сломано.
С другой стороны, но есть комбинации типа % в vim, Ctrl+Shift+M в Jetbrainsʼовских IDE, которые позволяют перейти в большинстве случаев на парную скобку (не уверен про begin-end).
Но в IDE есть и другие средства показа "где находишься", только надо стать внутрь блока.

K>Насколько всё это актуально в других языках? И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий, чтобы компенсировать недостаточную информативность самого кода? Вроде затраты на написание лишнего слова очень невелики.

Ставлю только когда считаю, что без него заметно неудобно (это достаточно редко).

K>Как видите, я не ставлю отступы — полагаю с такими стандартными комментариями они становятся не нужны.

Отступы надо ставить независимо от таких комментариев.

Здравствуйте, Khimik, Вы писали:

K>

K>case a of
K>1:begin
K>...
K>end; //q
K>2:begin
K>...
K>2nd; //2
K>end; //case
K>

Но почему после первого блока комментарий стоит "q"?

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

Здравствуйте, Khimik, Вы писали:

K>Я никогда не работал на работодателя, и у меня сформировался свой стиль писания кода. В частности, сложилась привычка писать стандартные комментарии. Не знаю как в других языках, а Delphi часто по коду без комментариев непонятно, что означает тот или другой end; (конец программной скобки).

Такой комментарий имеет смысл, если блок кода не влезает на экран. А если такой код написан,
то пора задуматься, что это порядочный говнокод и требует рефакторинга. Реально большие блоки
кода и такие комментарии нужны очень редко и обычно скорей встречаются в парах #ifdef/#endif
у C-макропроцессора, где иначе чёрт ногу сломит. Ещё namespaces в C++ бывают большие.

K>Есть много других аналогичных примеров: для case, для for и для произвольных программных скобок

Заставь дурака богу молиться -- лоб расшибёт.

K>Насколько всё это актуально в других языках?

Везде малоактуально.

K> И имеет ли смысл выработать привычку вообще во всех таких случаях писать стандартный комментарий,

Комментарии вида var x = y; (* x = y *) только вызывает желание долго пинать автора ногами.
Комментарий либо должен быть информативный, либо его не должно быть.

Здравствуйте, fmiracle, Вы писали:

F>Но почему после первого блока комментарий стоит "q"?

F>это, возможно, и ответ на твой вопрос — меняешь потом условие в if и надо не забыть поменять и комментарий иначе только путаница получится.

uncrustify, к слову, может ставить и исправлять эти метки автоматически.

Код имеет свойство рефакториться, а условия в if-ах — меняться. Обновлять каждый раз руками комментарий — бессмысленная работа на ровном месте. Достаточно один раз забыть поменять, а второй раз положиться на старый комментарий — и все, баг передает привет. А учитывая, что современные IDE умеют в code folding и bracket highlighting — занятие втройне бессмысленное.

Здравствуйте, Quebecois, Вы писали:

Q>Код имеет свойство рефакториться, а условия в if-ах — меняться. Обновлять каждый раз руками комментарий — бессмысленная работа на ровном месте. Достаточно один раз забыть поменять, а второй раз положиться на старый комментарий — и все, баг передает привет. А учитывая, что современные IDE умеют в code folding и bracket highlighting — занятие втройне бессмысленное.


Я пишу обычно как-то так, без условий:

while(...)
{
    if (...)
    {
        switch(...)
        {
        } // switch

    } // if 

} // while

Конкретные условия прописываю, только если несколько вложенных одинаковых конструкций, но это весьма редко

Кому как, мне так иногда удобнее

K>Не знаю как в других языках, а Delphi часто по коду без комментариев непонятно, что означает тот или другой end; (конец программной скобки).

Не нужно. Пиши так, чтоб читалось без комментариев. Или учись читать написанное.

K>

K>case a of
K>1:begin
K>...
K>end; //q
K>

q??? Вот и ответ по поводу ценности таких комментариев. Они с лёгкостью рассинхронизируются и только путают.

K>Насколько всё это актуально в других языках?

В Delphi это так же неактуально, как и везде.

Здравствуйте, Khimik, Вы писали:

Я комментирую закрывающую скобку у namespace как ns. Ещё могу иногда откомментировать конец большой функции как fn.

namespace omg {

    void wtf() {
        /* тут очень большая функция */
    } // fn

} // ns

namespace n1 { namespace n2 {
    // как-то так
} } // ns ns

Здравствуйте, удусекшл, Вы писали:

У>Я пишу обычно как-то так, без условий:
У>

У>while(...)
У>{
У>    if (...)
У>    {
У>        switch(...)
У>        {
У>        } // switch

У>    } // if 

У>} // while

У>

У>Конкретные условия прописываю, только если несколько вложенных одинаковых конструкций, но это весьма редко

Так тоже можно, но отступов достаточно.

Здравствуйте, yenik, Вы писали:

Y>q??? Вот и ответ по поводу ценности таких комментариев. Они с лёгкостью рассинхронизируются и только путают.

Вот кстати интересная мысль.

К примеру в bash пишется

if bla
then
 dosomething
fi

while bla
do
 dosomething
done

case soemthing
in
 pattern)
  dosomething
 ;;
esac

Там это часть синтаксиса. И я бы не сказал, что это такая уж плохая идея.

Здравствуйте, vsb, Вы писали:

vsb>Если конструкция вмещается на экран, это не нужно. Если не вмещается, значит надо её переписать, чтобы вмещалась.

если бы..

...
            } //if
          } //switch
        } // lock
      } // using
    } // method
  } // class
} // namespace

Вроде бы и конструкция — на экран, а декоративного срача — на три, как часто бывает.

S>Я комментирую закрывающую скобку у namespace как ns.

Просто используй File Scoped Namespaces

namespace EssentialCSharp10;

static class HelloWorld
{
    static void Main() { }
    // ...
}

Ведь ты же не используешь несколько пространств имён в одном файле?

S>Ещё могу иногда откомментировать конец большой функции как fn.

Не пиши функции, которые не влезают в экран нынешних огромных мониторов.