Длинные комментарии
Это новая версия статьи от 2022.11.26. Предыдущая от 2012.09.25 больше не актуальна.
Длинные комментарии в Си-образных языках неудобны из-за «/».
Этот символ находится на разных кнопках для латинской и русской раскладки.
Комментарий из Оберона «(*» и «*)» выглядят привлекательнее.
К тому же, такие комментарии дополнительно подчёркивают свою скобочную сущность и выглядят более естественно.
У скобок в роли первого и последнего символа комментария есть преимущество перед «/»:
скобками начинается и заканчиваются многие логически законченные конструкции.
Если эту конструкцию хочется просто отключить по какой-то причине, достаточно просто добавить звёздочки, чтобы превратить её в комментарий.
Например:
// было:
( некий блок )
// теперь отключаем:
(* некий блок *)
Как известно, комментарии вида /* ... */ не могут быть вложенными.
Сразу и не придумаешь, как элегантно обойти эту неприятность. Но решение нашлось.
Решение проблемы вложенности комментарией
Хотя масштаб этой проблемы невелик, однако хотелось бы решить её простым во всех отношениях способом.
Предложенные ранее решения («Помеченные комментарии» и
«Нерабочий код») хоть и реализуемы, но в них недостаточно простоты.
Наиболее элегантным решением видится такой вариант.
Комментарий начинается открывающей скобкой и некоторым количеством звёздочек: (*** .
Заканчивается комментарий симметрично: ***) .
Если попытаться закончить комментарий последовательностью символов с меньшим количеством звёздочек, например, **) ,
то окончания комментария в этом месте не будет: недостаточно звёздочек.
А вот если звёздочек больше, чем нужно, то лишние просто превращаются в текст комментария, а не являются элементом конструкции комментария.
(*** комментарий — это любой текст, располагающийся на
любом количестве строк. Жёлтый шрифт — это элементы конструкции
комментария, зелёный шрифт — собственно комментарий. «Лишние»
звёздочки не являются элементами конструкции комментария. *****)
Длинные комментарии (* ... *) можно вложить внутрь других, увеличив количество звёздочек:
(*** Комментарии с тремя звёздочками могут включать в себя
комментарии с двумя звёздочками и одной
(** Комментарии с двумя звёздочками могут включать в себя
комментарии с одной звёздочкой
(* Комментарий с одной звёздочкой
*)
**)
***)
У такого решения есть небольшой минус.
Лексический анализатор будет вынужден подсчитывать количество звёздочек.
Это исключит возможность разбора такого комментария регулярными выражениями.
То есть придётся прибегнуть к «хаку лексера».
Но заметных сложностей это не вызовет.
P.S. Запомним оценки статье к моменту изложения второй версии: 5/2/3/12. Посмотрим, как изменятся оценки дальше :)
P.P.S. Сколько раз убеждался, что если у людей, которые долго думают над одинаковыми вещами, часто приходят в голову одинаковые мысли.
Уже после того, как была готова вторая версия статьи, заново обнаружил для себя комментарий Александра Коновалова:
Интересен подход Rust (https://doc.rust-lang.org/reference/tokens.html#raw-string-literals) — строка, которая начинается с r#...#",
должна заканчиваться на "#...#, причём число решёток в начале и конце должно совпадать.
Т.е., строки могут иметь вид r"...", r#"..."#, r##"..."##. Соответственно, если строка содержит
"#### (кавычка и четыре решётки), то её можно погрузить в r#####"..."##### — (пять решёток).
Подход одинаковый: выше предложено делать комментарии с определённым количеством звёздочек, в Rust — решёточек.
Опубликовано: 2012.09.25, последняя правка: 2023.03.05 01:02
Отзывы
✅ 2014/12/25 01:00, Сергей #0
Лучше добавить вложенность пояснений. Часто так бывает, что нужно запояснить отрывок исходника, в котором уже есть пояснения. Этих пояснений может быть много, а отрывок может быть большим. Из-за отсутствия вложенности в таком случае придётся вручную удалять вложенные пояснения или их ограничители (в случае удаления ограничителей после распояснения охватывающего отрывка появятся ошибки, так что удалять придётся пояснения целиком), или же пытаться добавить возможность самодейного удаления вложенных пояснений в свою ЕСР (единую среду разработки). Кстати, в Глаголе пояснения могут быть вложенными. И это на самом деле очень удобно.✅ 2014/12/25 11:09, Автор сайта #1
Как раз про это: Нерабочий код.✅ 2021/03/27 12:14, Виталий Монастырский #2
Сущность многострочных комментариев — это комбинация символов, которые ГАРАНТИРОВАННО не могут быть встречены в программе вместе. Именно потому в Си — это // (два знака деления, которые не используются) и */ — деление и умножение, которое тоже не совместимо нигде и ни в каком виде.
У меня, к сожалению, // используется для извлечения корня, так что я такую комбинацию задействовать не могу, а потому ищу другие варианты. Пока остановился на базе собаки, так как она встречается только в адресах почты, а потому явно не может быть совместима ни с какими другими символами, включая кавычки. Возможность встретить такую комбинацию символов возможна только при их умышленном сочетании, что равносильно такому же употреблению */. Но, честно говоря, хотя комментарии в таком исполнении очень хорошо отделимы визуально, но все-таки кажутся пугающе огромными. Но на безрыбье и рак — щука, так что пока я оставил именно эту реализацию. Тем более, что для символа собаки все-равно трудно придумать разумное применение в языке.✅ 2021/03/28 00:00, alextretyak #3
Тем более, что для символа собаки все-равно трудно придумать разумное применение в языке. Трудно, но возможно. :)(:
Символ @ похож на английские буквы Ca, а потому в языке 11l используется[http://11l-lang.org/doc/ru/prefixes] в качестве префикса для обозначения captured-переменных [в языке Python для этого используется ключевое слово nonlocal, а в C++ — список захвата (capture list)].✅ 2021/03/28 10:22, Виталий Монастырский #4
Не вижу в этом смысла. Подобные техники рождаются из изначального несовершенства архитектуры языка и непродуманности его концепции разделения кода, миграции данных и политики области видимости. В моем языке все эти проблемы изначально решены другим подходом к этим вопросам и у меня просто нет необходимости каким-либо образом специально обрабатывать подобные виды передачи данных в функции.
Так что — нет, не подходит. Думайте еще... :)✅ 2021/04/01 13:13, Александр Коновалов aka Маздайщик #5
В моем языке все эти проблемы изначально решены другим подходом к этим вопросам и у меня просто нет необходимости каким-либо образом специально обрабатывать подобные виды передачи данных в функции. Поделитесь нам своим подходом. Добавить свой отзыв
Написать автору можно на электронную почту mail(аt)compiler.su
|