Комментарии C# при закрытии {}
https://stackoverflow.com/questions/323837
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я немного работал с DevExpress CodeRush и Refactor!Pro на этой неделе я приобрел плагин комментариев, который автоматически генерирует комментарии по мере ввода кода.
Я не хочу вдаваться в подробности, насколько хорошо он справляется с выделением основного значения (на самом деле, довольно хорошо), но его реализация по умолчанию вызывает вопрос.
По умолчанию ввод символа } для закрытия блока приведет к тому, что плагин добавит комментарий, подобный следующему:
using(MyType myType = new MyType())
{
myType.doWork();
} // using
(т.е.добавление комментария к закрывающей скобке, где она была открыта.)
Хотя я вижу, что есть случаи, когда такое поведение может быть очень полезно, я чувствую, что полученный код выглядит очень неопрятно со всеми дополнительными комментариями.
Мне было интересно, как другие люди относятся к такого рода комментариям.Не только с академической точки зрения: если я получу большое количество негативных комментариев о них, я смогу решить, навязать их своим коллегам или убрать их.
Решение
Думаю, подобные комментарии бесполезны, если, конечно, код не ужасен.При правильном форматировании кода нетрудно увидеть, где начинается и где заканчивается блок, поскольку обычно эти блоки имеют отступы.
Редактировать:Если процедура настолько велика, что не сразу понятно, какой блок кода закрывается фигурной скобкой, то в любом случае уже должно быть больше описательных комментариев, описывающих процедуру, и эти комментарии будут просто беспорядок.
Другие советы
Я считаю идею плагина, который генерирует комментарии из кода, довольно бесполезной. Если оно может быть выведено машиной, то оно также может быть выведено любым, кто его читает. Комментарии, скорее всего, будут полностью лишними.
Мне кажется, что закрывающий комментарий в скобках является грязным, он дает информацию, которая лучше предоставляется непосредственно IDE, если человек этого хочет.
ИМО каждый комментарий, который описывает то, что код уже говорит вам, не нужен.
Если у вас действительно есть блоки кода, которые настолько длинны, что вам нужно много прокручивать, чтобы увидеть начало, вы сделали что-то не так и можете разделить код на части.
Плохой стиль плохого комментария - он вносит накладные расходы в поддержку кода.
Я знал бывших VB-кодеров, которые находили следы } в коде C-синтаксиса запутанными, но в этом сценарии реальное исправление заключается в рефакторинге вашего кода для предотвращения глубокого вложения и чрезмерно длинные функции и / или кодовые блоки.
Может быть полезно, если блок using распространяется на страницу в IDE, но у вас есть другие проблемы, о которых нужно беспокоиться. В этом случае я получаю правильные отступы и интегрированную среду разработки, которая выделяет соответствующую фигурную скобку, когда я выбираю ее.
В общем, я делаю большие пальцы, но с потенциальным использованием, когда вы не можете избежать длинного блока в противном случае.
Иногда вы получите очень большие блоки кода или множество вложенных блоков, закрывающихся вместе. Я иногда использую этот стиль в подобных случаях, но определенно не всегда. Я не ограничиваю его также и кодом: HTML может очень выиграть от этого стиля «близкого комментирования»:
<div id="content">
<div id="columns">
<div class="column">
<!-- .. snip a lot of lines .. -->
</div> <!-- .column -->
</div> <!-- #columns -->
</div> <!-- #content -->
Комментарии такого рода полезны только для очень длинных блоков кода, где у вас много вложенных блоков. Но это сказало, что это не должно иметь место во-первых, поскольку много вложенных блоков и длинных методов требуют рефакторинга. Так что мне это совсем не нравится, поскольку читатель, очевидно, может видеть, что это за блок кода.
Я думаю, что более полезной, чем комментарии, была бы функция IDE, позволяющая не только выделить совпадающие пары фигурных скобок, но и отобразить открывающую строку на всплывающей подсказке, так что если вы наведете курсор на закрывающую фигурную скобку в своем примере, она получит " использование (MyType myType = new MyType ()) " во всплывающей подсказке.
Это позволит вам легко понять сложные вложенные фигурные скобки для больших функций без постоянного визуального беспорядка.
Мне всегда полезно помнить об этом ...
Ясный, хорошо написанный код предоставит достаточное объяснение того, что делает код, чтобы компетентный программист мог его подобрать.
В коде следует оставить комментарии, объясняющие почему код делает это!
Другими словами, используйте комментарии, чтобы помочь читателю вашего кода понять алгоритм или то, что код должен достигать , а не как его достичь!
Возможно, вы захотите проверить этот пост Джеффа Этвуда .
Не делайте этого, он просто добавляет шум, если используется повсеместно, и помимо правильного отступа должен решить проблему читабельности.
Я бы оставил его выключенным. Я вижу смысл в использовании этого, когда у вас есть несколько блоков, заканчивающихся в одном месте (более длинные или более короткие блоки) - я использовал их сам в некоторых случаях, подобных этим. Однако, если они используются, было бы лучше добавить их вручную, в тщательно отобранных местах, а не с помощью какого-либо автоматического инструмента, добавляющего их.
Если вам необходимо решить, пригоден ли определенный тип комментариев или нет, то, скорее всего, последний.
Комментарии предназначены для объяснения определенных блоков кода или сущности в целом, чтобы облегчить понимание; не облегчать чтение форматирования.
Наличие плагина, всегда соответствующего этому поведению, является и ожирением, и уродливым.
Я согласен, что есть гораздо лучшие способы описать, что делает код.
Если у вас длинный код, которому предшествует один информативный комментарий, например // Исправить рабочий элемент, вы можете взять этот код и изменить его как собственный метод. Затем используйте комментарий в качестве имени нового метода FixWorkItem (). Это быстрый способ сделать ваш код более самодокументированным и может даже выявить некоторые особенности дизайна, которые вы раньше не замечали.
Следите за однострочными комментариями, такими как потенциальные рефакторинги, которые могут обрабатываться IDE автоматически. Код, который документирует сам себя, лучше, чем даже самые написанные отдельные комментарии, за исключением, конечно, описания намерений.
