Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Комментарии

В процессе эволюции языков программирования сложилось так, что оказались жизнеспособными два вида комментариев: длинные (с условно скобочной структурой) и короткие, занимающие конец строки. В Си они представлены /*...*/ и //... соответственно. В последнее время появились комментарии третьего вида: комментарии генерации документации. Идея замечательна: прокомментировал функцию, и этим одновременно создал help для неё.

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

            Экспериментируя с компиляцией кодов C++, мне захотелось сделать так, чтобы длинные комментарии могли бы быть вложенными. Ведь они по сути — квази-скобки: /* и */. Одна квази-скобка открывает комментарий, а вторая закрывает. Это очень удобно. Допустим, имеется фрагмент программы:

 текст программы
/* комментарий */
 текст программы
             Если мне надо для каких-то целей этот фрагмент закомментировать целиком, сделать его нерабочим, то содержащийся внутри комментарий этому совершенно не мешает: число открывающих скобок равно числу закрывающих. И у нас всё хорошо.

             Но от этого пришлось отказаться. В C++ комментарии не могут быть вложенными, для совместимости со стандартом языка следует отказаться от такой возможности. Так почему в C++ вложенные комментарии невозможны? Это казалось идиотизмом, которому нет разумных объяснений. Ведь это так элементарно! Объяснение нашлось случайно. Допустим, у нас есть такой кусок программы:
   char  x[] = "*/";                      // строка n+1
   /* комментарий */                      // строка n+2
   // ещё какой-то код                    // строка n+3
А теперь весь этот фрагмент поместим внутрь другого комментария:
/* начало комментария верхнего уровня     // строка n
   char  x[] = "*/";                      // строка n+1
   /* комментарий */                      // строка n+2
   // ещё какой-то код                    // строка n+3
конец комментария верхнего уровня */      // строка n+4
            При компиляции этого текста будет обнаружена ошибка. Комментарий верхнего уровня, начинающийся в строке n, закончится не в строке n+4 и даже не в строке n+2, а в строке n+1. Может возникнуть возражение:

Пусть компилятор сделает синтаксический анализ и увидит, что «*/» в строке n+1 заключен в кавычки, т.е. «*/» — это строковый литерал. Эта пара символов не может быть концом комментария, пусть компилятор ищет этот конец дальше

.             Это возражение не может быть принято! Компилятор не должен проводить анализ внутри комментария. Единственное, что можно ему позволено — это искать символы «*/».

            Но что же тогда делать? Иметь вложенные скобочные комментарии всё равно хочется. Мы, например, скопировали фрагмент кода из другой программы и хотим иметь его в качестве образца. Или ещё по каким-то причинам нужно фрагмент программы сделать неработающим, отключить его. Варианты решения проблемы:
  • Один из вариантов выхода видится такой. К тем видам комментариев, которые уже имеются, нужно добавить ещё один. Специально для того, чтобы фрагменты программ делать неработающими. Внутри таких комментариев делается синтаксический анализ, но выходной код для таких участков программы не генерируется. Этот другой вид комментариев и начинаться должен по-другому, т.е. не так, как обычный длинный (скобочный) комментарий. Но это сложный вариант.

  • Второй вариант — комментарии, имеющие уникальную метку вначале и конце. Этот способ попроще.

  • Ну и самое лёгкое — вообще ничего не делать. Просто программист должен знать о таком нюансе и самостоятельно отслеживать такую редкую ситуацию — последовательность символов «конец комментария» внутри строки.

Опубликовано: 2012.09.25, последняя правка: 2018.11.09    12:43

ОценитеОценки посетителей
   ██████████████████████████████████████████ 5 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Отзывы

     2014/06/17 04:26, utkin          # 

Есть ещё один вид комментариев это #. Он является стандартом в юникс/линукс.

     2014/06/17 16:43, Автор сайта          # 

Просто жаль целый символ жертвовать на какой-то комментарий. А вдруг пригодится? Уж лучше тогда «##», это не так жалко :)

     2016/08/06 19:05, rst256          # 

А разве одиночные комментарии не удобнее? Они же надежно отключают любой код, и гораздо быстрее обрабатываются.

     2016/08/12 10:21, Трурль          # 

Но эта же ошибка возникнет и без вложенных комментариев.

     2021/03/27 11:56, Виталий Монастырский          # 

У меня тоже введены дополнительные виды комментариев. Один из них — это "комментирование кода", специальный вид комментария, предназначенный именно для закрытия отдельных блоков кода во время компиляции. Так же есть ещё пара системных комментариев, в которых я храню настройки для компилятора и константы для словарей автозамены.

Так что полностью поддерживаю автора в необходимости расширения списка комментариев, согласно их функциям.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  О неправомерном доступе к памяти через указатели

●  Обработка ошибок

●  Функциональное программирование

●●  Нечистые действия в чистых функциях

●●  О чистоте и нечистоте функций и языков

●●  Макросы — это чистые функции, исполняемые во время компиляции

●●  Хаскелл, детище британских учёных

●●  Измеряем замедление при вызове функций высших порядков

●●  C vs Haskell: сравнение скорости на простом примере

●●  Уникальность имён функций: за и против

●●  Каррирование: для чего и как

●●  О тестах, доказывающих отсутствие ошибок

●  Надёжные программы из ненадёжных компонентов

●●  О многократном резервировании функций

●  Использование памяти

●  Почему динамическое распределение памяти — это плохо

●  Как обеспечить возврат функциями объектов переменной длины?

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/03/28 13:26 ••• Ivan
Энтузиасты-разработчики компиляторов и их проекты

2024/03/27 19:12 ••• MihalNik
Постфиксные инкремент и декремент

2024/03/22 20:41 ••• void
Раскрутка компилятора

2024/03/20 19:54 ••• kt
О многократном резервировании функций

2024/03/20 13:13 ••• Неслучайный читатель
Надёжные программы из ненадёжных компонентов

2024/03/10 18:33 ••• Бурановский дедушка
Русской операционной системой должна стать ReactOS

2024/03/07 14:16 ••• Неслучайный читатель
«Двухмерный» синтаксис Python

2024/03/03 16:49 ••• Автор сайта
О неправомерном доступе к памяти через указатели

2024/02/28 18:59 ••• Вежливый Лис
Про лебедей, раков и щук

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты