Синтаксический сахар вызывает рак точек с запятой

Примеры

Массивы в Си представляют собой блоки в памяти. Доступ к элементам массива производится через указатель на начало блока памяти (то есть, на начало массива) и смещение элемента относительно начального адреса. Это может быть записано без использования специального синтаксиса для массивов ( a — указатель на начало массива, i — индекс необходимого элемента, size — размер элемента данного типа в памяти): *(a + i * size) , но непосредственные операции с адресами в памяти и смещениями являются большим источником ошибок программистов, поэтому язык предоставляет специальный синтаксис: a[i] . Кроме того, для массивов с size = 1 есть возможность обратиться к i -му элементу массива уж совсем экзотическим способом: i[a] , что аналогично a[i] , так как значение указателя i+a , очевидно, равно a+i .

Другой известный пример специализированной языковой конструкции — тернарная условная операция языка Си ?: . Следующие два фрагмента кода делают одно и тоже:

Причина введения такой операции — желание вставлять проверку простых условий прямо в выражения и возможность прямо указать компилятору, что результатом проверки условия будет единственное значение. Конструкция действительно сокращает запись, но вот по поводу её удобства мнения могут быть разными. Многие считают, что сокращение записи в данном случае не окупает ухудшение читаемости кода.

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

Критика

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

Чаще критика направляется на отдельные, часто встречающиеся виды синтаксического сахара: переопределение операций, свойства, сложные операции (вроде вышеупомянутой тернарной операции ?: в Си). Доводы критиков, в основном, сводятся к тому, что подобные средства, в действительности, не делают программу ни проще, ни понятнее, ни эффективнее, ни короче, но приводят к дополнительной трате ресурсов и усложняют восприятие, а значит и сопровождение программы.

Синтаксическая соль

Директива override в Delphi явно указывает на то, что помеченный ею метод подменяет виртуальный метод класса-родителя. Наличие этой директивы требует от компилятора проверить соответствие сигнатуры подменяющего и подменяемого метода, так что при изменении в базовом классе программист будет вынужден внести те же изменения в классы-потомки, иначе программа не будет компилироваться.
Операция reinterpret_cast в C++ обеспечивает небезопасное преобразование типа. Операция не производит никакого кода, она лишь обходит контроль типов. Единственный смысл её использования — напоминание, что подобное небезопасное преобразование типов использовано намеренно.

В дополнение к if…else, JavaScript имеет функцию, известную как заявление switch. switch представляет собой тип условного оператора, который будет оценивать выражение в отношении нескольких возможных случаев и выполнит один или несколько блоков кода на основе сопоставления случаев. Утверждение switch тесно связано с условным оператором, содержащего множество блоков else if, и они часто могут быть взаимозаменяемыми.

В этой статье мы научимся использовать заявление switch, а также научмся использовать соответствующие ключевые слова case, break и default. Наконец, мы узнаем, как использовать несколько выборов в заявлении switch.

Switch

Оператор switch вычисляет выражение и выполняет код в результате сопоставления случая. Сначала это может выглядеть немного пугающе, но основной синтаксис подобен заявлению if. Он всегда будет написан как switch () <>, со скобками, содержащих выражение для проверки, а также фигурные скобки, содержащие потенциальный код для выполнения.

Ниже приведен пример заявления switch с двумя заявлениями case, и запасным вариантом, известным как default.

Следуя логике блока кода выше, это последовательность событий, которые будут иметь место.

Выражение Switch

Первым case x будет проведена проверка в отношении выражения. Если они совпадают, то этот код выполниться, а ключевое слово break будет в конце блока switch.
Если он не соответствует будет пропущен x, и будет протестировано выражения y. Если y соответствует выражению, то код выполниться и выйдет из блока switch.
Если ни один из случаев не совпадают, то выполниться код блока default.

Давайте сделаем пример рабочего оператора switch после указанного выше синтаксиса. В этом блоке кода, мы найдем текущий день недели с new Date()методом, и с помощью getDay() напечатаем номер, соответствующий текущему дню. Понедельник начинается с единицы, и так продолжается до 7, которая является воскресеньем. Мы начнем с создания нашей переменной.

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

Этот код был проверен на четверг, что соответствует 4, поэтому вывод на консоль будет: “Еще один день до выходных!”. В зависимости от того, в какой день недели вы тестируете код, ваш выход будет отличаться. Мы включили блок default в конце, чтобы запустить в случае ошибки, которая в данном случае не должна произойти, поскольку есть только семь дней в неделю. Мы могли бы, например, распечатать результаты понедельника по пятницу, и блок default мог иметь такое же сообщение на выходные.

Если бы мы опустили ключевое слово break в каждом заявлении, ни один из других утверждений case не был бы оценено истинно, но программа продолжала бы проверять, пока не дошла до конца. Для того, чтобы сделать наши программы быстрее и эффективнее, мы включаем break.

Диапазон Switch

Возможно, возникнет случай, в котором вам нужно будет оценить диапазон значений в блоке switch, в отличие от одного значения, как в нашем примере выше. Мы можем сделать это, установив выражение true и делать операцию в каждом сообщении case.

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

Оценка от 90 и выше является A
Оценка от 80 до 89 является B
Оценка от 70 до 79 представляет собой С
Оценка от 60 до 69 является D
Оценка от 59 или ниже является I

Теперь мы можем написать, это в заявлении switch. Поскольку мы делаем проверку диапазона, мы будем выполнять операцию в каждом case, чтобы проверить, что каждое выражение вычисляем как true, а затем выполним заявление после того, как требования к true было удовлетворено.

Выражение в скобках, оценивается как true в данном примере. Это означает, что любое, case которое вычисляется как true будет выполнено.

Так же, как с else if, switch оценивается сверху вниз, и первое выполненное условие будет выполнено. Поэтому, так как наша переменная grade равна 87, следовательно, имеет значение true для C и D, но выводиться первым B.

Множественные Cases

Вы можете столкнуться с кодом, в котором несколько case должны иметь один и тот же вывод. Для того, чтобы достичь этого, вы можете использовать более одного case для каждого блока кода.

Чтобы проверить это, мы собираемся сделать небольшое приложение, соответствующее текущему месяцу у соответствующего сезона. Во- первых, мы будем использовать метод new Date(), чтобы найти номер, соответствующий текущему месяцу, и применим его к переменной month.

Метод new Date().getMonth() будет выводить число от 0 до 11, с 0 это январь и 11 будет декабря. Во время этой публикации, месяц сентябрь, который будет соответствовать 8.

Наше приложение будет выводить четыре сезона со следующими характеристиками для простоты:

Зима : январь, февраль и март
Весна : апрель, май и июнь
Лето : июль, август и сентябрь
Осень : октябрь, ноябрь и декабрь

Когда мы запустим этот код, мы получим вывод, идентифицирующий текущий сезон, основанный на спецификации выше.

Текущий месяц на момент публикации был 8, что соответствует одному из заявлений case с выходом сезона “Лето”.

Вывод

В этой статье мы рассмотрели заявление switch, тип заявления conditonal, которое вычисляет выражение и выводит различные значения на основе сопоставления результатов. Мы рассмотрели заявление switch, используя диапазон и несколько заявлений case.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Синтаксический сахар, IMHO, как правило, делает программы гораздо более удобочитаемыми и понятными, чем кодирование из очень минималистичного набора примитивов. Я действительно не вижу обратной стороны хорошего, хорошо продуманного синтаксического сахара. Почему некоторые люди в основном думают, что синтаксический сахар в лучшем случае излишен, а в худшем-что-то, чего следует избегать?

Edit: я не хотел называть имена, но поскольку люди спрашивали, похоже, что большинство программистов C++ и Java, например, откровенно не заботятся о полном отсутствии синтаксического сахара в их языке. Во многих случаях это не обязательно означает, что они просто любят другие части языка достаточно, чтобы сделать отсутствие сахара достойным компромисса, это то, что они действительно не заботятся . Кроме того, программисты Lisp, похоже, почти гордятся странной нотацией своего языка (я не буду называть ее синтаксисом, потому что это технически не так), хотя в данном случае она более понятна, потому что позволяет метапрограммирующим средствам Lisp быть такими же мощными, как и они.

Синтаксический сахар вызывает рак точки с запятой. Алан Перлис

Трудно рассуждать о синтаксическом Сахаре, если рассуждение происходит без привязки к контексту. Существует множество примеров того, почему "syntactic sugar"-это хорошо или плохо, и все они бессмысленны без контекста.

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

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

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

некоторые конкретные примеры:

Первый-это c# (или java) специфический, автоматический бокс и конструкция блокировки / синхронизации

В этом примере полезная конструкция блокировки, которая может использовать любой объект в качестве точки синхронизации, в сочетании с автобоксингом, приводит к возможной ошибке. Замок просто берется на новый упакованный экземпляр i каждый раз. Можно спорить, что конструкция замка слишком полезна и что какая-то другая конкретная конструкция, на которой можно было бы запереться, была бы лучше, но, конечно, комбинация все еще несовершенна.

Объявление и указатели множественных переменных:

Классическая ошибка (хотя ее легко обнаружить). Сахар из нескольких переменных не будет соответствовать объявлению указателя.

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

Широко используемая конструкция (и та, которая сама имеет область для ошибок, так как вы должны помнить, чтобы обновить обе переменные, если вы хотите изменить от использования i). Однако, поскольку это легко встроить в другие выражения, вопрос префикса и постфикса поднимает свою голову. При использовании в цикле for это не имеет значения, оценка происходит вне любых других оценок, но при использовании в другом месте она может быть источником путаницы (поскольку вы можете встроить очень важный аспект вычисления (следует ли использовать текущее или следующее значение) в очень маленькую и легко пропускаемую форму.

Все вышеперечисленное (за исключением, возможно, блокировки / коробки, которую компилятор действительно должен определить для вас) - это случаи, когда использование вполне может быть прекрасным, или опытные программисты могут думать "that's perfectly clear to me", но область для путаницы существует, конечно, для начинающих программистов или тех, кто переходит к другому синтаксису.

Слишком много ненужного сахара просто добавляет вздутия языкам. Я называл имена, но потом меня просто сжигали. :) Кроме того, иногда язык использует синтаксический сахар вместо того, чтобы делать реальную реализацию. Например, есть язык, который останется безымянным, чей "generics implementation" - всего лишь тонкий слой синтаксического сахара.

Ерунда. C и Lisp программисты постоянно используют синтаксический сахар.

a[i] вместо *(a+i)
'(1 2 3) вместо (quote 1 2 3)

Посмотрите на закон дырявых абстракций - слишком много сахара, и вы просто используете его, не понимая и не зная, что происходит, и это делает его все более трудным для отладки, если что-то пойдет не так. Дело не столько в том, что "syntactic sugar"-это плохо, просто многие программисты полагаются на него, не осознавая на самом деле, от чего они защищены, а затем, если синтаксический сахар сталкивается с проблемами, они облажаются.

Лично я всегда находил термин "syntactic sugar" двусмысленным. Я имею в виду, если вы хотите получить техническую информацию, почти все, что угодно, кроме основной арифметики, оператора if, а goto-это синтаксический сахар.

Я думаю, что большинство людей имеют в виду, когда они отвергают "syntactic sugar", что языковая особенность делает что-то сложное чрезмерно простым. Самый печально известный пример этого-Perl. Но поскольку я не являюсь экспертом Perl, я приведу вам пример того, о чем я говорю в python (взято из этого вопроса ):

Это очевидная попытка сделать что-то более простое, которое пошло ужасно, ужасно неправильно.

Но это не значит, что я на стороне удаления таких функций. Я думаю, что такие функции просто нужно использовать осторожно.

Я всегда понимал "syntactic sugar" как ссылку на любой синтаксис, добавленный к существующему языку, который не расширяет возможности языка. В противном случае все менее прямое, чем двоичный машинный язык, можно было бы назвать синтаксическим сахаром.

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

Например, LINQ-это синтаксический сахар, потому что он не добавляет никаких новых возможностей к C#3, которые уже были невозможны в C#2., но чтобы сделать то же самое, что простое выражение LINQ в C#2, потребовалось бы значительно больше кода, чтобы выполнить его, и было бы гораздо труднее читать.

И наоборот, универсальные выражения не являются синтаксическим сахаром, потому что с ними в C#2 можно делать то, что было невозможно с C#1,, например создавать класс коллекции, который может содержать любой тип значения без бокса.

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

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

Возможно, потому, что это приводит к путанице в программистах, которые не знают, что на самом деле происходит за кулисами, что, в свою очередь, может привести к неэффективному или плохо написанному коду.. Просто предположение, я тоже не думаю, что это "bad thing".

Синтаксический сахар может либо сделать вашу программу более понятной, либо сделать ее менее понятной. Если вы добавляете синтаксический сахар для тривиальных вещей, вы просто добавляете когнитивную нагрузку, потому что язык становится более сложным. С другой стороны, если вы можете добавить синтаксический сахар, который каким-то образом позволяет точно определить конкретное понятие и выделить его, то вы можете выиграть.

Это больше типизации и больше слоев абстракции. Я бы предпочел использовать язык, который предназначен для более высоких уровней абстракции, чем язык с синтаксическим сахаром, прикрепленным к плохой работе по имитации функций, встроенных в другие языки.

Лучший пример полезного сахара — точка с запятой. Вот код:
a=1+(2*b+c) b
компилятор поймёт, что b — начало нового утверждения. На самом деле хотели написать:
a=1+(2*b+c)*b
Если после и будет точка с запятой, то нет сомнений, где заканчивается утверждение. Здесь синтаксический сахар — дополнительная подстраховка.
Я нахожусь где-то посередине между этими подходами. Я склоняюсь к преимуществам Паскалевской точки зрения, чтобы находить ошибки во время компиляции, а не во время выполнения. Но я ненавижу просто бросаться словами без явной причины, как в COBOL. Я могу позволить синтаксическому сахару существовать в небольшом количестве.

Второе возражение. Цитирую:

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

Теперь вернёмся к теме разговора.

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

При этом разделение труда таково. Программист вводит текст программы. Этот текст максимальным образом лишён всех синтаксических излишеств. А вот IDE по мере ввода программистом программы, анализирует его и дополняет графикой ! Для программиста синтаксический сахар возникает сам по себе. Он не прикладывает для этого дополнительных усилий. Каков должен быть сахар — решает сам программист, меняя настройки IDE. Нужно сопровождать элементы конструкций графикой — программист выставляет соответствующие настройки IDE. Для каждого типа графических элементов.

Оцените	Оценки посетителей
Нравится	█████████████████████████ 22 (57.8%)
Неплохо	██████████████ 12 (31.5%)
Так себе	███ 2 (5.26%)
Не нравится	███ 2 (5.26%)

2013/04/18 20:13, Михаил #

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

2013/04/19 13:45, Автор сайта #

2013/04/23 14:25, Михаил #

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

2013/04/25 11:07, Автор сайта #

2016/08/10 20:23, rst256 #

Я с вами полностью согласен, так почему же вы с собой не согласны:

Вы же прекрасно понимаете что "then" просто лексический сепаратор, не важно, что вы задействуете в его качестве. Для языков, чей синтаксис не позволяет без сепаратора точно определять конец выражения "then" и ";" необходимы компилятору не меньше чем Си-строке нультерминирующий символ. Я приводил пример языка Lua, где реализовано "мягкое отсечение" для выражений. Вы согласны, что "then" и ";" надо убрать, значит надо убрать:

1. "x = (if x==y; -a; else -b)" — условный оператор внутри выражения должен быть как в си, а для трех и более этажных выражений более подойдет конструкция аналогичная сишной "(< . ; . ; . >)"

2. "-a=. ; *a=. ;" и все иные унарные операции, совпадающие с бинарными в начале нового предложения, быть не должно. Можно сделать "--" и "++" в этой части постфиксными, ну а разадресация у вас уже и так не конфликтует.

В синтаксисе, который описан на данный момент, других препятствий более нету.

2016/08/19 03:26, rst256 #

А как насчет разделителя после последнего элемента списка? Например "," в списке аргументов функции, элементы перечисления и т.п. Есть ли резон принудительно их запрещать?
Это один из самых "невкусных" видов синтаксического сахара, который заставляет и компилятор и программиста делать лишнюю работу.

2016/08/20 06:27, rst256 #

Как вам язык ВООБЩЕ с разделителями только когда это необходимо?Так делается в языке Lua где нет разделителей между отдельными командами, однако допустимо их явное указание. На нем код "а1=55+1 а2=а1+3" эквивалентен коду "а1=55+1; а2=а1+3;", и оба этих варианта допустимы в языке.

Правда, разделители между аргументами функций "," там все же есть. Но почему бы не пойти дальше?

Например, многие языки программирования предоставляют специальный синтаксис для ссылок и обновления массива элементов. Отвлеченно, ссылка на массив представляет собой процедуру из двух аргументов: массив и вектор индекса, которые могут быть выражены как get_array(Array, vector(i,j)) . Вместо этого многие языки предоставляют синтаксис , такие как Array[i,j] . Аналогично обновление элемента массива представляет собой процедура из трех аргументов, например set_array(Array, vector(i,j), value) , но многие языки предоставляют синтаксис , такие как Array[i,j] = value .

содержание

1 Происхождение
2 Известные примеры
3 Критика
4 Производные условия
- 4,1 Синтаксическая соль
- 4.2 Синтаксический сахарина
5 Примечания
6 Ссылки

происхождения

Известные примеры

В COBOL , многие из промежуточных ключевых слов синтаксический сахар , который необязательно может быть опущен. Так , например, предложение MOVE A B. и предложение MOVE A TO B. выполнить точно такую же функцию, но второй делает действие , которое будет выполняться более четким.
Дополненное назначение или назначение соединения операторы: Например, a += b эквивалентно a = a + b в С и подобными языками, предполагая a имеет никаких побочных эффектов , такие как , если a есть регулярная переменный.
В Perl , unless (condition) <. >является синтаксически if (not condition) <. >. Кроме того, любое заявление может сопровождаться условием, так statement if condition что эквивалентно if (condition) , но бывший более естественно , отформатированные на одной строке.
В языке Си , то a[i] обозначение синтаксический *(a + i) . Аналогичным образом, a->x обозначение синтаксический сахар для доступа пользователей с помощью оператора разыменования (*a).x .
using Заявление в C # гарантирует , что некоторые объекты утилизированы правильно. Компилятор расширяет заявление в примерочных , наконец , блок.
# Язык C позволяет переменные должны быть объявлены в качестве var x = expr , что позволяет компилятору вывести тип x из выражения expr , вместо того , чтобы требовать явного объявления типа. Аналогично, С ++ допускает auto x = expr так C ++ 11.
Python списочные (например, [x*x for x in range(10)] для получения списка квадратов) и декораторов (например @staticmethod ).
В Haskell , строка, обозначенная в кавычках, семантически эквивалентно списку символов.
В R , то труба , обозначается %>% , говорит о том , что данные (или выходе функции) , предшествующие трубы будут служить в качестве первого аргумента функции следующей трубы. Это дает больше линейного потока и конструкции манипулирования данными. Tidyverse написано для размещения труб.

критика

Производные финансовые условия

Метафора была распространена чеканки термин синтаксический соль , что указывает на возможность разработан , чтобы сделать это труднее писать плохой код. В частности, синтаксический соль представляет собой обруч , что программисты должны прыгать через только , чтобы доказать , что они знают , что происходит, вместо того , чтобы выразить действие программы. Например, в Java и Pascal назначая значение с плавающей точкой к переменной , объявленной как межд без дополнительного синтаксиса явно о том , что намерение приведет к ошибке компиляции, в то время как C и C ++ автоматически обрезает любые поплавки , назначенных на междунар. Однако это не синтаксис, а семантика.

В C # , скрытие унаследованного члена класса, предупреждение компилятора выдается , если new не используется ключевое слово , чтобы указать , что скрытие является намеренным. Для того, чтобы избежать возможных ошибок вследствие схожести переключателя заявления синтаксиса с тем, что из C или C ++, C # требует break для каждой непустой case метки switch (если goto , return или throw не используются) , даже если он не допускает неявный обходя переход . (Использование goto и указав последующий ярлык производит C / C ++ - как падение-через .)

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

Альтернатива синтаксической соли генерации предупреждений компилятора, когда существует высокая вероятность того, что код является результатом ошибки - практика, распространенные в современных компиляторов C / C ++.

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

Заметки

11 ответов

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

некоторые определенные примеры:

первым является c# (или Java) определенная, Автоматическая упаковка и блокировать/синхронизировать конструкция

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

Несколько объявление переменной и указатели:

ошибка классика А (хотя легкий для определения). Сахар нескольких переменных не будет соответствовать объявлению указателя.

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

, А широко использовал конструкцию (и тот, который сам имеет объем для ошибок, так как необходимо не забыть обновлять обе переменные, если Вы хотите измениться от использования i). Однако, так как это легко встроить в рамках других выражений, проблема префикса и постфикса возникает. При использовании в для цикла это не имеет значения, оценка происходит за пределами любых других оценок, но используемый в другом месте это может быть источник беспорядка (так как можно встраивать очень важный аспект вычисления (должно ли текущее или следующее значение использоваться) в очень маленькую и легко пропущенную форму.

Все вышеупомянутое (кроме, возможно, того блокировки/поля, которое компилятор действительно должен определить для Вас) случаи, где использование может быть прекрасным, или опытные программисты могут думать, что "это совершенно ясно мне", но объем для беспорядка существует, конечно, для программистов новичка или тех, которые перемещаются в другой синтаксис.

Читайте также: