О вреде синтаксического сахара
О чём речь? Конечно, использование синтаксического сахара не приводит к синтаксическому диабету, но он может мешать вам думать. Это может звучать странно, учитывая, что синтаксический сахар призван облегчить нам жизнь: обернуть в интуитивные обёртки операции над абстракциями, сделать программы легко читаемыми, да и просто симпатичными. Однако, всякий инструмент, который направляет нашу мысль одновременно удерживает её на этом направлении.
Ситуация здесь как в анекдоте о дорогах, в котором американец хвастается:
— Я когда еду по дороге, ставлю стакан с водой на капот и гоню со скоростью 100 км/час. Ни одна капля воды не расплескается.
На что русский говорит:
— А мы все залезаем на заднее сиденье и всю дорогу в карты режемся, да пиво пьём.
— А кто же машиной управляет.
— Да куда она, на хрен, из колеи денется.
Смешно, но, однако, удобно, я бы даже позавидовал тем ребятам на заднем сиденье если бы у меня не было синтаксического сахара. Колея хороша тем, что она позволяет не думать о том, как ты едешь, синтаксический сахар позволяет не думать о том, как ты пишешь, освобождая мозг для концентрации на задаче. Но что если для решения задачи мне понадобится сделать что-то странное? Съехать с колеи? Проблема даже не в том, что из неё сложно выбраться, она в том, что это колея для наших мыслей — нам просто не придёт в голову, что есть другие способы сделать дело.
Но довольно теории, пришло время замарать руки. Приведу пример. Допустим, мы пишем ORM и в определённый момент нам понадобилось получить список имен полей модели, чтобы, к примеру, составить SQL запрос. Также, допустим, что поля — это объекты, у которых есть свойство name, содержащее имя поля. Всего-то делов! Надо просто пробежаться по всем полям, вытащить имя и составить список:
var names = [];
for ( var i = 0 , l = fields.length; i < l; i ++ ) names.push(fields[i].name);
>
Похоже, мы пишем ORM на javascript-е, ну ничего, люди делают куда более странные вещи в наши дни. И кстати, мы попали в первую ловушку синтаксиса — «пробежаться» интерпретировали как цикл, и в результате получили пару переменных, сравнение целых чисел, инкремент и квадратные скобки. Чёрт возьми! Это не то, что я имел в виду, когда говорил «пробежаться»! Попробуем ещё раз:
var names = fields.map( function (field) return field.name;
>);
Короче, симпатичнее и куда ближе к тому, как я описывал алгоритм: пробежаться по полям — fields.map, получить имя — функция, которая получает имя. Н-да, функция, как бы от неё избавиться? Легко, не будем сдерживать себя, перепишем всё на питоне:
names = [field . name for field in fields]
Одна строчка! Казалось бы, мы достигли идеала, но на самом деле этот вариант в некотором смысле даже хуже предыдущего: его тяжело расширять и практически невозможно повторно использовать. Да ну? Давайте попробуем, предположим нам вдруг понадобилось иногда приписывать алияс таблицы перед именами полей:
names = [ » %s . %s » % (alias, field . name) if alias
else field . name for field in fields]
Это уже не выглядит так здорово, а что если нам потребуется приписать алияс для поля? И ведь потребуется, не это так что-то ещё. Что ж не будем ждать, когда наш код выйдет из под контроля, отрефакторим его превентивно:
if alias:
names = [ » %s . %s » % (alias, field . name) for field in fields]
else :
names = [field . name for field in fields]
Ясность вернулась, но появилось дублирование. Это не случайно, списковые выражения, которые мы используем связывают в одну синтаксическую структуру пробежку и операцию над отдельным элементом. Не проблема, просто должно остаться только одно списковое выражение:
if alias:
get_name = lambda field: » %s . %s » % (alias, field . name)
else :
get_name = lambda field: field . name
names = map (get_name, fields)
… или ни одного — как только мы избавились от запутывания пробежки и операции списковое выражение стало ненужным. Тут есть ещё один интересный момент — мы вернулись к тому, что у нас было в javascript-е. Т. е. отсутствие в языке такого сладкого элемента как списковые выражения, привело к написанию более универсального кода. Неправда ли отличный пример «less is more», товарищи?
Итак, я «расправился» с циклом for и питоньими списковыми выражениями, пора идти дальше. Вам нравится обращаться к свойствам объекта через точку? Мне — очень, это кратко (кроме самого объекта и требуемого свойства присутствует только маленькая точка) и экспрессивно (даже человек далёкий от объектов легко поймёт в чём тут соль). Это настолько удобно, что мы не вспоминаем об альтернативах, а в том же питоне есть три способа получить атрибут объекта (прямое обращение к __getattr__ и т.п. — чит, не дающий ничего принципиально нового):
obj . name
getattr (obj, «name» )
operator . attrgetter( «name» )(obj)
Нас интересует последний, самый жуткий вариант, потому что он превращает операцию доступа к атрибуту в функцию. Ту самую, которую мы эмулируем с помощью лямбды. Если бы это был единственный способ получить атрибут, то мы сразу бы написали универсальный, расширяемый и готовый к повторному использованию код:
from operator import attrgetter
names = map (attrgetter( «name» ), fields)
Может сложиться впечатление, что я предлагаю отказаться от синтаксиса — нет, это важная часть большинства современных языков, обеспечивающая читаемость и экспрессивность кода. В конце концов, я тоже не против в меру подсластить код. Что я хочу сказать — важно видеть за синтаксисом суть того, что ты делаешь, уметь отодвинуть синтаксис так, чтобы код выражал задачу и чтобы отдельные части задачи ложились на отдельные синтаксические элементы.
P.S. Я не пишу ORM на javascript-е.
P.P.S. Я не пишу ORM и на питоне, хотя временами я копаюсь в ORM Django.
P.P.P.S. Странная идея, изложенная здесь, пришла ко мне во время чтения Practical Common Lisp. Для тех, кто не в курсе, программа на лиспе представляет собой набор вложенных списков, каждый из которых состоит из “что делать” (имени функции, оператора или макроса) и последующих аргументов, т.е. представляет синтаксическое дерево самой себя. Другими словами в Lisp нет синтаксиса. И как ни странно, это делает программы на нём удивительно гибкими.
UPDATE. Чтобы ответить на большинство возражений, подойду несколько с другой стороны. Заметим, что map(), который я в конце концов использую, тоже абстракция довольно высокого уровня. На самом деле используемые мной абстракции можно выстроить в иерархию:
C-style for + абстрагирование от индексирования = for-in
for-in + возврат результата на каждой итерации = map
map + lambda = списковое выражение.
Я начинаю с низкого уровня и дохожу до уровня абстракции, который лучшим образом выражает то, что я пытаюсь сделать. И если мне не нужно обобщать, то здесь я и должен остановиться, но если обобщать приходиться я должен вспомнить, что списковое выражение — это просто map и lambda в одном флаконе или начать дублировать код. Если в языке нет списковых выражений (как в js), то я сразу получу обобщённый код, но он будет более низкоуровневым. Если я забуду о том, что списковое выражение можно разбить, то начну дублировать код.
Подытоживая:
1. Отсутствие определённого синтаксиса в языке приводит к написанию более гибкого кода.
2. Этот более гибкий код будет более низкоуровневым.
Второе плата за первое,
Синтаксический сахар
Синтаксический сахар (англ. syntactic sugar ) — термин, обозначающий дополнения синтаксиса языка программирования, которые не добавляют новых возможностей, а делают использование языка более удобным для человека.
Определение
«Синтаксический сахар» — это любой элемент синтаксиса языка программирования, который даёт программисту альтернативный способ записи другой, уже имеющейся в языке синтаксической конструкции, и при этом является более удобным, или более кратким, или похожим на другой распространённый способ записи, или помогает писать программы в хорошем стиле. С формальной точки зрения синтаксический сахар ничего не меняет и выразительности языку не прибавляет, однако может заметно облегчить программисту описание некоторых операций. Одновременно синтаксический сахар, особенно при его неумеренном применении, может ухудшать читаемость кода и усложнять его поддержку. Конструкции, являющиеся синтаксическим сахаром, могут легко транслироваться в конструкции основного синтаксиса.
Необходимо отметить, что понятие синтаксического сахара во многом условно. Его использование предполагает, что из всего множества синтаксических конструкций можно выделить некоторый «базовый набор», обеспечивающий всю функциональность языка, и тогда дополнительные синтаксические средства, которые при желании можно выразить с помощью базового набора, и будут для данного языка синтаксическим сахаром. Однако многие конструкции являются взаимозаменяемыми, и далеко не всегда можно определённо сказать, какие именно из них являются базовыми, а какие — дополнительными. Например, в языке Модула-2 есть четыре вида циклов: цикл с предусловием, цикл с постусловием, цикл с шагом и безусловный цикл. Теоретически, первые три вида циклов могут быть легко выражены через последний. Являются ли они, в таком случае, синтаксическим сахаром? Обычно так не говорят, хотя формально под вышеприведённое определение они попадают.
Примеры
Массивы в Си
Массивы в Си представляют собой блоки в памяти. Доступ к элементам массива производится через указатель на начало блока памяти (то есть, на начало массива) и смещение элемента относительно начального адреса. Это может быть записано без использования специального синтаксиса для массивов ( a — указатель на начало массива, i — индекс необходимого элемента, size — размер элемента данного типа в памяти): *(a + i * size) , но непосредственные операции с адресами в памяти и смещениями являются большим источником ошибок программистов, поэтому язык предоставляет специальный синтаксис: a[i] . Кроме того, для массивов с size = 1 есть возможность обратиться к i -му элементу массива уж совсем экзотическим способом: i[a] , что аналогично a[i] , так как значение указателя i+a , очевидно, равно a+i .
Тернарная операция в Си
Другой известный пример специализированной языковой конструкции — тернарная условная операция языка Си ?: . Следующие два фрагмента кода делают одно и тоже:
int fn(); int a = 1; int b; if (a > 0) b = fn(1); else b = fn(2);
int fn(); int a = 1; int b = fn((a > 0)? 1 : 2);
Причина введения такой операции — желание вставлять проверку простых условий прямо в выражения и возможность прямо указать компилятору, что результатом проверки условия будет единственное значение. Конструкция действительно сокращает запись, но вот по поводу её удобства мнения могут быть разными. Многие считают, что сокращение записи в данном случае не окупает ухудшение читаемости кода.
Переопределение операторов
К синтаксическому сахару можно отнести и переопределение операторов, поддерживаемое многими языками программирования. В принципе, любая операция может быть оформлена как процедура (функция, метод). Переопределение операторов позволяет выполнять операции, созданные программистом, внешне так же, как и встроенные в язык.
Свойства
Ещё одним примером синтаксического сахара является концепция «свойств», поддерживаемая многими современными языками программирования. Имеется в виду объявление в классе псевдополей, которые внешне ведут себя как поля класса (имеют имя, тип, допускают присваивание и чтение), но в действительности таковыми не являются. Каждое обращение к свойству преобразуется компилятором в вызов метода доступа. Свойства совершенно не являются необходимыми (методы доступа можно вызывать и непосредственно) и используются исключительно для удобства, поскольку код с использованием свойств выглядит несколько проще и понятнее.
Критика
Не все программисты считают наличие синтаксического сахара в языках программирования и использование его программистами благом. Известна точка зрения Никлауса Вирта, которую разделяет часть программистского сообщества: согласно ей, любое расширение языка, не вызванное необходимостью, ухудшает его, так как приводит к усложнению транслятора и, соответственно, к понижению его надёжности и производительности. Одновременно возрастает сложность изучения языка и сложность сопровождения программ. Кроме того, сам факт наличия дополнительных синтаксических средств часто играет провоцирующую роль: он побуждает программиста прибегать к различным синтаксическим трюкам вместо того, чтобы глубже анализировать задачу и реализовывать более эффективные алгоритмы. Эти взгляды отразились в языках семейства Оберон, очень простых и практически лишённых синтаксического сахара.
Известен афоризм Алана Перлиса: «Синтаксический сахар вызывает рак точек с запятой». Точка с запятой («;»), являясь обязательной частью большинства популярных языков программирования, даже если в новом языке бесполезна, оставляется как необязательный элемент, так как большинство программистов имеют прочную привычку её использования. В оригинале афоризм обыгрывает созвучие английских слов semicolon (точка с запятой) и colon, последнее из которых означает не только двоеточие, но и толстый кишечник (colon cancer — рак толстого кишечника).
Чаще критика направляется на отдельные, часто встречающиеся виды синтаксического сахара: переопределение операций, свойства, сложные операции (вроде вышеупомянутой тернарной операции ?: в Си). Доводы критиков, в основном, сводятся к тому, что подобные средства, в действительности, не делают программу ни проще, ни понятнее, ни эффективнее, ни короче, но приводят к дополнительной трате ресурсов и усложняют восприятие, а значит и сопровождение программы.
Синтаксическая соль
В противоположность «синтаксическому сахару» в понятие «синтаксическая соль» (англ. syntactic salt ) [1] на жаргоне хакеров обозначает конструкции в языке программирования, которые необходимо употреблять при выполнении потенциально небезопасных действий. Таким образом, используя их, программист подтверждает, что сомнительное действие предпринято им сознательно, а не является случайной ошибкой или результатом непонимания. Так же, как «синтаксический сахар» не добавляет языку выразительности, «синтаксическая соль» не расширяет возможности языка и не нужна транслятору для корректной компиляции программы; она предназначена исключительно для людей, пользующихся данным языком. Классическим примером общеизвестной и широко применяемой «синтаксической соли» являются имеющиеся почти в любом языке со статической типизацией встроенные команды преобразования типов данных. Формально эти команды излишни (что доказывает классический язык Си, где любое преобразование типов допустимо и выполняется автоматически), но в языках, где их применение обязательно, программист вынужден каждый раз обращать внимание на то, что он выполняет потенциально опасное смешение типов (которое часто указывает на логическую ошибку в программе). В зависимости от строгости языка программирования использование «синтаксической соли» может быть обязательным или факультативным. В первом случае транслятор воспринимает её отсутствие как синтаксическую ошибку, во втором — выдаёт при трансляции предупреждение, которое программист может проигнорировать. В отличие от «синтаксического сахара», который расширяет свободу выражения программиста, «синтаксическая соль» её сужает, требуя «без причины» писать длинные конструкции.
В Jargon File написано: «синтаксическая соль вредна, поскольку повышает артериальное давление хакера». Действительно, при написании небольших программ, создаваемых и поддерживаемых одним человеком, предосторожности могут показаться излишними, однако при промышленной разработке крупных программных комплексов, поддерживаемых большими коллективами программистов (зачастую, к тому же, не самой высокой квалификации), «синтаксическая соль» помогает не ошибаться в разработке и эффективнее разбираться в коде, написанном другими разработчиками.
- Директива override в Delphi явно указывает на то, что помеченный ею метод подменяет виртуальный метод класса-родителя. Наличие этой директивы требует от компилятора проверить соответствие сигнатуры подменяющего и подменяемого метода, так что при изменении в базовом классе программист будет вынужден внести те же изменения в классы-потомки, иначе программа не будет компилироваться.
- Операция reinterpret_cast в C++ обеспечивает небезопасное преобразование типа. Операция не производит никакого кода, она лишь обходит контроль типов. Единственный смысл её использования — напоминание, что подобное небезопасное преобразование типов использовано намеренно.
Примечания
Литература
JavaScript: Синтаксический сахар
Подобные конструкции index = index + 1 в JavaScript используются довольно часто, поэтому создатели языка добавили сокращённый вариант записи: index += 1 . Такие сокращения принято называть синтаксическим сахаром, потому что они делают процесс написания кода немного проще и приятнее, «подслащивая» его 🙂
Существуют сокращённые формы для всех арифметических операций и для конкатенации строк:
- a = a + 1 → a += 1
- a = a — 1 → a -= 1
- a = a * 2 → a *= 2
- a = a / 1 → a /= 1
- a = a + ‘foo’ → a += ‘foo’
Задание
Реализуйте функцию filterString() , принимающую на вход строку и символ, и возвращающую новую строку, в которой удален переданный символ во всех его позициях. Регистр символов важен.
const str = 'If I look back I am lost'; filterString(str, 'I'); // 'f look back am lost' filterString('zz Zorro', 'z'); // ' Zorro' Упражнение не проходит проверку — что делать? ��
Если вы зашли в тупик, то самое время задать вопрос в «Обсуждениях». Как правильно задать вопрос:
- Обязательно приложите вывод тестов, без него практически невозможно понять что не так, даже если вы покажете свой код. Программисты плохо исполняют код в голове, но по полученной ошибке почти всегда понятно, куда смотреть.
В моей среде код работает, а здесь нет ��
Тесты устроены таким образом, что они проверяют решение разными способами и на разных данных. Часто решение работает с одними входными данными, но не работает с другими. Чтобы разобраться с этим моментом, изучите вкладку «Тесты» и внимательно посмотрите на вывод ошибок, в котором есть подсказки.
Мой код отличается от решения учителя ��
Это нормально ��, в программировании одну задачу можно выполнить множеством способов. Если ваш код прошел проверку, то он соответствует условиям задачи.
В редких случаях бывает, что решение подогнано под тесты, но это видно сразу.
Прочитал урок — ничего не понятно ��
Создавать обучающие материалы, понятные для всех без исключения, довольно сложно. Мы очень стараемся, но всегда есть что улучшать. Если вы встретили материал, который вам непонятен, опишите проблему в «Обсуждениях». Идеально, если вы сформулируете непонятные моменты в виде вопросов. Обычно нам нужно несколько дней для внесения правок.
Кстати, вы тоже можете участвовать в улучшении курсов: внизу есть ссылка на исходный код уроков, который можно править прямо из браузера.
Полезное
Определения
- Синтаксический сахар — это синтаксические возможности, применение которых не влияет на поведение программы, но делает использование языка более удобным для человека.
Что такое синтаксический сахар
Иногда на форумах и в комментариях опытных коллег-программистов можно услышать что-то вроде «Это просто синтаксический сахар, не обращай внимания». Давайте разберёмся, что это такое, зачем оно нужно и откуда такое название.
Что такое синтаксический сахар
Синтаксический сахар — это способ написания кода, чтобы сделать его более понятным для программиста. Иногда сахар нужен для того, чтобы сделать код короче, оставив ту же самую логику. При этом на работу программы такое оформление вообще не влияет — при запуске компьютер упрощает код, выбрасывает сахар и исполняет суть программы.
Можно сделать код короче
Проще всего синтаксический сахар показать на примерах. Допустим, у нас значение одной переменной зависит от другой:
// исходная переменная var st = "true"; // если она истинна if (st == "true") < // то присваиваем второй переменной 'Y' var hasName = 'Y'; >else < // иначе присваиваем второй переменной 'N' var hasName = 'N'; >;Этот же самый фрагмент можно записать короче, используя синтаксический сахар — тернарный оператор, который обрабатывает сразу три параметра:
hasName = name ? ‘Y’ : ‘N’;
Этот код делает всё то же самое:
- Проверяет, в name — истина или ложь.
- Если истина — присваивает переменной hasName значение ‘Y’.
- Иначе присваивает ей значение ‘N’.
Логика работы и действия остались точно такими же, но второй код получился компактнее, чем второй, хотя для новичка он выглядит гораздо сложнее.
Сделать код проще
Есть сахар, который, наоборот, делает код проще. Например, вот классический способ организовать цикл, чтобы вывести все его элементы на экран:
// объявляем простой цикл, чтобы вывести все элементы массива for (let i = 0; i
А вот то же самое, но с синтаксическим сахаром:
for (const element of massiv)
Здесь сразу понятно, что мы перебираем все значения массива massiv, кладём их в переменную element и выводим её на экран.
Ещё примеры синтаксического сахара
В большинстве случаев мы даже не задумываемся над тем, что используем синтаксический сахар в своём коде. Но часто с ним удобнее, чем без него:
Например, вот классический способ сделать объект в JavaScript:
var obj = new Object();
А вот более короткий вариант с сахаром:
Первая строчка — классический способ завести пустой массив, вторая — более привычный сахарный способ:
var arr = new Array();
var arr = [];
Если в JavaScript нужно проверить что-то с помощью регулярных выражений, переменную с этим выражением можно задать двумя способами: традиционным и с сахаром. Сделают они одно и то же, просто вторая будет короче:
var regex = new RegExp(‘something’);
var regex = /something/;
А вот пример чистого сахара. Мы объявляем анонимную функцию, и тут же её выполняем:
В каких языках есть синтаксический сахар
Почти во всех языках программирования есть сахар, причём чем высокоуровневее язык, тем больше сахара можно в нём встретить. Меньше всего сахара в Ассемблерах и в странных языках типа Brainfuck.
Обязательно ли использовать сахар в коде
Использовать синтаксический сахар необязательно, на то он и сахар. Программа с ним и без него будет работать одинаково. Другое дело — как потом эту программу будут поддерживать и обновлять, но и тут есть нюанс. Программа с сахаром может выглядеть читаемее, а может, и менее читаемо — зависит от того, какие именно конструкции вы используете.
Когда код пишут начинающие разработчики, они чаще используют код без сахара, чтобы дисциплинировать себя и сделать код максимально читаемым для себя же. Со временем, начитавшись StackOverflow и набравшись опыта, они нахватаются разных оформительских и структурных привычек и будут использовать тот сахар, который им будет казаться самым полезным. А следующие за ними новички будут смотреть на их код и ничего не понимать.