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

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

Не готов предложить новых идей. Хотя мне нравится короткий комментарий из языка Ада «--», но эту последовательность симолов лучше оставить декременту.
Вариации на тему коротких комметариев в уже существующих языках:
«//»        C-подобные языки
«--»        Ada
«*»         x-Base
«'»         Visual Basic
«;»         Assembler, Lisp, Scheme
«#>         Python
            Если ли большой смысл отказываться от Си-шного короткого комментария «//»? В языке Ада нет декремента, поэтому там легко использовать «--». Символы «*», «'», «;» и «#» слишком ценны, чтобы их целиком отдавать под короткий комментарий. Двойные «**», «''» и «;;» — это было бы приемлемее и не так расточительно.

             Наверное, «//» вполне подходящ. Хотя «;;» и «##» тоже неплохи.

Пример:

        // короткий комментарий — это любой текст до конца строки
        ;; можно и такой комментарий попробовать
        ## и такой тоже

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

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

Отзывы

     2012/10/05 08:22, utkin          # 

«#» Python
Это имеет логичное объяснение. Питон в основном обосновался в линукс/юникс. Там # фактически стандарт комментария (из-за коммандных интерпретаторов).

     2014/01/31 09:36, Pensulo          # 

Позвольте раскритиковать ваши варианты решения данного вопроса в пух и в прах.
Удвоенный знак умножения мог бы вполне себе использоваться как обозначение операции возведения в степень (z = x ** y ).
Удвоенный знак одинарной кавычки визуально почти не отличается от одинарного знака двойной кавычки ('' = ").
Удвоенный знак точки с запятой можно было бы вполне себе законно трактовать как пропущенный оператор, а вовсе не как знак комментария ( a = b;; c = a ), если одинарный знак при этом обозначает ещё и завершение оператора.
Обилие знаков # затемняет собственно текст самого комментария и к тому же требует переключения раскладки на английский язык, если конечно не разрешить также альтернативное употребление "кириллического" знака №.
Последнее замечание, кстати справедливо и для знака правый слэш, который, для освобождения от необходимости скакать по раскладкам, предпочтительнее было бы заменить на левый слэш.

Кстати, в VisualBasic вопрос с комментариями решён весьма органичным способом — употреблением знака одинарной кавычки. При этом, надо иметь ввиду, что в языке синтаксически нет длинных комментариев, что не мешает однако длинные комментарии употреблять. В этом случае используются возможности IDE по автоматическому предварению (или наоборот устранению) каждой строки выбранного блока знаком короткого комментария. Практика показывает что такое решение также устраняет и проблему употребления вложенных длинных комментариев.

Всё таки в M$ разработчики не даром едят свой хлеб, по крайней мере в том подразделении которое занимается VB.

     2014/01/31 15:13, Автор сайта          # 

Насчёт «**», «;;», «#» согласен с Вами. Использование «\\» как начало короткого комментария — хорошая идея. Правда, ещё один товарищ, обсуждающий со мной черты языка, предлагает использовать обозначение «\» как операцию целочисленного деления, а «\\» — как взятие остатка от деления.

Идея перепоручить среде разработки делать длинные комментарии из нескольких коротких не нравится. Программист должен иметь возможность работать без этой среды, в простом текстовом редакторе.

Одинарная кавычка пригодится в другом качестве. В PHP текстовые литералы можно заключать как в двойные, так и в одинарные кавычки. Это удобно: когда в среди символов встречаются двойные кавычки, то литерал надо заключить в одинарные. И наоборот.

     2014/04/23 02:31, Utkin          # 

// Есть и в Си и в Паскале, на цифровой клавиатуре вводится на любой раскладке. Вполне годный вариант комментария.

     2014/05/23 06:46, Pensulo          # 

Utkin
Я, прошу прощения, но уже давно работаю сугубо за ноутбуками разных моделей и обособленную цифровую часть клавиатуры уже давно не использую (вследствие различий её реализации в разных моделях ноутбуков). Посему не вижу для себя удобства в употреблении знака '/'.
Кстати, хотя вы наверняка это знаете, однако напомню что клавиша помеченная как '.' на цифровой части клавиатуры зависит от региональных настроек текущего выбранного языка ввода. В русском это — запятая, а в английском — точка. И это тоже отбивает охоту использовать эту часть клавиатуры.

Автор сайта
Предложение по взятию остатку через "\\" — хорошее, но в этом конфликте функций надо предпочесть одно другому исходя из наибольшей важности для проектируемого языка, например, ориентируясь на частотность задействования той или иной функции.

     2014/06/17 04:30, utkin          # 

Pensulo
Очевидно, что здесь нет однозначного ответа и надо идти на компромисс. То есть чем-то жертвовать: либо удобством, либо традициями, либо ясностью и т.д. И ещё — все-таки ноуты по-прежнему не предназначены для серьезной работы. Я понимаю, работа, поездки и все такое, но пока факт остается фактом — ноуты не предназначены для серьезной и длительной работы над большими проектами (тут и клава и экран и усталость программера).

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

Так получилось, что я уже 9-й год с одним и тем же ноутбуком и дома, и на работе, и в дороге. Уже привык. Обычная клавиатура меня уже раздражает.

     2020/08/04 23:06, Иван          # 

Чем плох короткий комментарий Фортрана: ! <комментарий>?

     2020/08/04 23:42, Автор сайта          # 

Символ «!» традиционно используют для обозначения унарной логической операции «не». Если этот символ использовать для короткого комментария, то для «не» придётся придумывать другое обозначение.

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

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

Авторизация

Регистрация

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

Карта сайта


Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●  Циклы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компилятор

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

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

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

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




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

2020/09/30 22:50 ••• Автор сайта
Утилита транслитерации русского C/C++ в стандартный

2020/09/30 22:44 ••• Автор сайта
Синтаксический сахар

2020/09/20 21:24 ••• Неслучайный читатель
Философия языка

2020/08/04 23:42 ••• Автор сайта
Короткие комментарии

2020/07/30 11:04 ••• kt
О PL/1 и почему в нём не зарезервированы ключевые слова

2020/07/29 10:00 ••• Тимофей
Энтузиасты-разработчики компиляторов и их проекты

2020/06/21 15:05 ••• рст256
Русский язык и программирование

2020/06/08 21:53 ••• kt
Поддержка профилирования кода программы на низком уровне

2020/05/02 20:59 ••• Denis Juriev aka D.V.J.
В защиту PL/1

2020/03/28 17:28 ••• Comdiv
Программирование без программистов — это медицина без врачей

2020/02/05 19:59 ••• Александр Коновалов aka Маздайщик
Обработка ошибок

2020/01/25 12:55 ••• kt
Тест. Какой Вы программист?