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

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

Текст программ обычно читаем легче, если пишется по правилу «один оператор — одна строка». К тому же символ «перевод строки» лучше сигнализирует об окончании оператора, нежели символ «;» Потому что «;» — обычный символ, который можно и не заметить по невнимательности. «Перевод строки» не заметить трудно. Он, выполняя роль разделителя выражений, страхует от досадных ошибок, по сути опечаток, такого вида:

	if (a > b);              // эта точка с запятой не всегда бросается в глаза
	    a = 0;
	for (i=0; i<100; i++);   // здесь такая же беда
	    function();
        Здесь употребление лишних «;» приводят к изменению смысла программы. Но удалять напрочь «;» из языка в качестве разделителя не стоит, пусть он выполняет эту роль наряду с «переводом строки». Просто язык нужно спроектировать так, чтобы даже такие «;» не приводили к ошибкам. Чтобы упомянутый выше пример можно было бы записать двумя способами, которые оба правильны:
	(if a > b
	    a = 0)
	(for i=0; i<100; i++
	    function())
или
	(if a > b; a = 0)
	(for i=0; i<100; i++; function())
            Равноцены ли «перевода строки» и «;», могут ли они употребляться на равных? В целом да, за исключением тех случаев, когда некоторые операторы языка требуют наличия переред собой исключительно «перевода строки». Т.е когда оператор должен быть первым в строке. Соответственно, этому должен предшествовать «перевод строки». Что это за операторы? Это оператор выхода из цикла и продолжения цикла.

            Если оператор не помещается на одной строке и её надо продолжить на следующей, в Си такую строку заканчивают символом «\». Не эстетично. Наиболее привычным и естественным для человеческого глаза в этом случае будет троеточие:
     ЭтотОченьДлинныйОперраторБудетПродолженВследующейСтрокеИвЭтомНамПоможетТроеточие...
     ВтораяЧастьДлинногоОператора 

     A = B + ...
           C	// оператор закончен только здесь	
            Продолжить оператор на другой строке можно и без троеточия:
     вызов функции (первый параметр с очень длинным именем,
                    второй параметр с очень длинным именем)
     сумма = первый аргумент с очень длинным именем +
             второй аргумент с очень длинным именем
            Разорвать имя на две строки мы не можем. А вот перенести идентификатор на другую строку можно, потому что необходимость продолжать строку очевидна. В конце строки стоит либо знак препинания, либо знак операции. Это стоит сделать правилом: если строка заканчивается знаком препинания (точка, запятая, двоеточие) или знаком операции, то она продолжается на следующей непустой строке. В этом случае желательно отказаться от постфиксных унарных операторов, ведь они идут после операнда. В Си имеется только две таких операции — постфиксные инкремент и декремент, но от них желательно избавиться по другим причинам. Нам достаточно просто не придумывать новых.

Опубликовано: 2012.09.25, последняя правка: 2018.10.29    16:03

ОценитеОценки посетителей
   ████████████████████████████ 2 (66.6%)
   ██████████████ 1 (33.3%)
   ▌ 0
   ▌ 0

Отзывы

     2014/01/26 11:26, Pensulo          # 

В VisualBasic разделителем операторов является символ двоеточия. И при желании всю подпрограмму можно уложить в одну строку потеряв только в читабельности кода.
Неявным разделителем операторов является также и перевод строки.
Продолжить незавершённый оператор на следующую строку при этом можно символом нижнее подчёркивание.
Кстати среда разработки заботится о соблюдении завершённости операторов весьма жёстким образом не допуская ошибок уже на этапе ввода программы.

     2014/01/26 17:39, Автор сайта          # 

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

Когда среда разработки предостерегает от ошибок — это хорошо, именно к этому есть стремление.

     2016/04/01 22:48, rst256          # 

Перевод строки является весьма естественным способом обозначить конец выражения.

Особенно когда ты работаешь с выражениями большой длины, не вмещающиеся на одну линию экрана!

     2016/04/03 15:01, Автор сайта          # 

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

     2016/04/11 17:24, rst256          # 

Вообще нетерминал выражение не имеет четко обозначенного окончания, для аргументов при вызове ф-и это обычно ")" и ",", для присваивания это или окончание операции или "," если язык позволяет множественное присваивание, как тот же си. Также могут быть особые формы для условного оператора и циклов (в си они соответствуют аналогичным для вызова ф-и, кроме условия в цикле for, там это ";")
По сути мы обсуждаем не способ обозначить конец выражения, а способ конкатенации выражения разбитого на несколько строк. И в данном вопросе я считаю самый удобный способ обозначения это. Т.е. ничего, мягкое отсечение. А всякие иные способы это следствие ущербности парсера! Я захотел разбить выражение на 2-е строки — я нажал enter, больше ничего я нажимать не должен!

     2016/04/11 18:21, Автор сайта          # 

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

     2016/07/03 13:14, rst256          # 

если строка заканчивается знаком препинания (точка, запятая, двоеточие) или знаком операции, то она продолжается на следующей непустой строке.

код:
  целое ф1()
целое ц1=55!
ф1()
и код который должен был быть:
  целое ф1()
целое ц1=551
ф1()
Удачной отладки, ошибки не будет :-)
Я выбираю не менее "надежный" вариант с разделителем ";", там хотя бы есть возможность скомпоновать код и не плодить сто срок с операциями в 5-6 знаков в каждой. Или вообще без разделителя как в языке Lua, но это уже сложнее будет распарсить.

     2016/07/03 13:52, Автор сайта          # 

Т.е. Вы считате, что код
ц1=55!
ф1()
будет компилятором понят как
ц1=55!ф1()
и сообщений об ошибках не будет. Сообщения будут. Во-первых, операция «!» — префиксная унарная. Между двумя операндами должна быть инфиксная операция, иначе ошибка. Во-вторых, если функция в первом примере ф1 ничего не возвращает , то и во втором случае операция «!» не может быть применена к вызову процедуры (или функции типа void — в терминах Си). Если же ф1 ведёт себя подобно функциям Си, когда результат функции может быть не востребован (например, хочу — пишу
a=getchar()
но могу и проигнорировать результат:
getchar()
это в Си не будет ошибкой), то это плохой стиль. Недаром в функциональных языках игнорирование результата, выдаваемого функцией, вызывает ошибку при компиляции.

Разделителей, как Вы помните, два вида: точка с запятой и перевод строки. Они равноправны. Так что при желании можно размещать несколько операторов на одной строке.

Равноцены ли «перевода строки» и «;», могут ли они употребляться на равных? В целом да, за исключением тех случаев, когда некоторые операторы языка требуют наличия переред собой исключительно «перевода строки». Т.е когда оператор должен быть первым в строке. Соответственно, этому должен предшествовать «перевод строки». Что это за операторы? Это оператор выхода из цикла и продолжения цикла.

От этого, наверное, нужно отказаться.

     2016/10/29 14:19, rst256          # 

Да, вы правы: к скрытым ошибкам подобный способ разделения операторов не приведет. Думаю, в таком случае предложенный вами способ разделения будет наиболее удобным и лаконичным из все возможных.

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

У меня тоже используется перевод строки, а для её переноса троеточие.

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

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

Авторизация

Регистрация

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

Карта сайта


Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●  Циклы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компилятор

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

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

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

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




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

2024/03/29 14:49 ••• 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 ••• Клихальт
Избранные компьютерные анекдоты