Одне ще ніхто не згадував, тому я зазначу це: Бажання вкладати коментарі часто вказує на те, що програміст робить це неправильно.
По-перше, погодимось, що єдиний час, коли "вкладення" або "не вкладення" видно програмісту, коли програміст пише щось структурно так:
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. Але це лише конкретне застосування препроцесора С, яке є самим великим і корисним інструментом. Насправді, мовою було б дуже важко і особливо важко підтримувати умовну компіляцію з, #ifале ще не підтримувати #if 0.
Отже, ми встановили, що вкладені коментарі є актуальними лише тоді, коли програміст коментує код; і ми встановили (за умови консенсусу багатьох досвідчених програмістів), що коментувати код - це погана річ.
Щоб завершити силогізм, ми повинні визнати, що мовні дизайнери зацікавлені в просуванні добрих речей і відволіканні від поганих речей (якщо вважати, що всі інші рівні).
У разі вкладених коментарів, все інше є рівним - ви можете сміливо ігнорувати низько проголосував відповіді , які стверджують , що розбір вкладені /*буде яким - то чином бути «важким» для синтаксичного аналізу. (Вкладені /*не складніше, ніж вкладені (, з якими майже кожен аналізатор у світі вже повинен впоратися.)
Отже, при рівності, чи повинен мовний дизайнер легко вносити коментарі (тобто коментувати код) чи важко? Нагадаємо, що коментувати код - це погана річ.
QED
Зноска Зверніть увагу, що якщо ви не дозволяєте вкладені коментарі, тоді
hello /* foo*/bar.txt */ world
є оманливим "коментарем" - це рівнозначно
hello bar.txt */ world
(що, ймовірно, синтаксична помилка). Але якщо ви робите дозволити вкладені коментарі, то
hello /* foo/*.txt */ world
є оманливим "коментарем" - це рівнозначно
hello
але залишає коментар відкритим аж до кінця файлу (що знову ж таки майже напевно є синтаксичною помилкою). Тож жоден спосіб не є особливо схильним до ненавмисних синтаксичних помилок. Єдина відмінність полягає в тому, як вони обробляють навмисний антипатент коментованого коду.