Одна вещь, которую еще никто не упомянул, поэтому я упомяну это: желание вкладывать комментарии часто указывает на то, что программист делает это неправильно.
Во-первых, давайте согласимся, что единственный раз, когда «вложение» или «не вложение» видимо программисту, это когда программист пишет что-то структурно подобное:
do_something();
/* comment /* nested comment */ more comment */
do_something_else();
Теперь, когда такая вещь возникает на практике? Конечно, программист не собирается писать вложенные комментарии, которые буквально похожи на приведенный выше фрагмент! Нет, на практике, когда мы вкладываем комментарии (или хотим, чтобы мы могли их вкладывать), это потому, что мы хотим написать что-то вроде этого:
do_something(); /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/
И это плохо. Это не образец, который мы (как языковые дизайнеры) хотим поощрять! Правильный способ написания фрагмента коды выше:
do_something(); /* do a thing */
Этот «неправильный» код, этот фальстарт или что бы то ни было, не входит в кодовую базу. Это относится, в лучшем случае, к истории контроля версий. В идеале, вы бы никогда не написали неправильный код для начала, не так ли? И если неправильный код служил цели там, предупреждая сопровождающих не восстанавливать его по какой-то причине, ну, это, вероятно, работа для хорошо написанного и намеренного комментария кода. Попытка выразить «не делай X», просто оставив в некотором старом коде, который делает X, но закомментирован, не самый читаемый или эффективный способ помешать людям делать X.
Все это сводится к простому практическому правилу, которое вы, возможно, слышали раньше: не закомментируйте код. (Поиск по этой фразе повернет вверх много из мнений в соглашении .)
Перед тем, как задать вопрос: да, такие языки, как C, C # и C ++ уже дают программисту еще один инструмент для «закомментировать» большие блоки кода: #if 0. Но это всего лишь частное применение препроцессора C, который сам по себе является большим и полезным инструментом. На самом деле для языка было бы крайне сложно и специально для него поддерживать условную компиляцию, #ifно не поддерживать ее #if 0.
Итак, мы установили, что вложенные комментарии актуальны только тогда, когда программист комментирует код; и мы установили (благодаря консенсусу многих опытных программистов), что комментирование кода - плохая вещь.
Чтобы завершить силлогизм, мы должны принять тот факт, что разработчики языка заинтересованы в продвижении хороших вещей и предотвращении плохих вещей (при условии, что все остальное равно).
В случае вложенных комментариев, все остальное является равным - вы можете смело игнорировать низко проголосовал ответы , которые утверждают , что разбор вложенные /*будет каким - то образом быть «трудным» для синтаксического анализа. (Вложенные /*не сложнее, чем вложенные (, с которыми почти каждый парсер в мире уже должен обращаться.)
Итак, при прочих равных, должен ли языковой дизайнер упростить вложение комментариев (т. Е. Комментировать код) или это сложно? Напомним, что комментирование кода - плохая вещь.
QED
Сноска. Обратите внимание, что если вы не разрешите вложенные комментарии, то
hello /* foo*/bar.txt */ world
вводящий в заблуждение «комментарий» - это эквивалентно
hello bar.txt */ world
(что, вероятно, является синтаксической ошибкой). Но если вы делаете разрешить вложенные комментарии, то
hello /* foo/*.txt */ world
вводящий в заблуждение «комментарий» - это эквивалентно
hello
но оставляет комментарий открытым до самого конца файла (что опять-таки почти наверняка является синтаксической ошибкой). Таким образом, ни один из этих способов не менее подвержен непреднамеренным синтаксическим ошибкам. Единственное отличие состоит в том, как они обрабатывают преднамеренный антипаттерн закомментированного кода.