In computer science, syntactic sugar is linguistics in a programming language. It is designed to make code easier, more readable and expressive. This sugar makes the tongue “sweeter” for human use. That is, things can be expressed clearly, concisely, or in an alternative style that some may prefer.
Syntactic sugar: what is it?
Many programming languages provide a special grammar department for updating items. Abstract, a reference to this object is a procedure of two arguments: an array and a subscript, which can be expressed as get_array(Array, vector(i, j))
. Instead, many languages provide syntax such as Array [i, j]
. Similarly, updating an array element, for example, set_array(Array, vector(i, j), value)
, is a three-argument procedure, but many professionals provide code such as Array[i, j] = value
.
A construct in a language is called “syntactic sugar” if it can be removed from the program without any impact on functionality and expressiveness.
Various processors, including compilers and static analyzers, often extend sweetened designs to more fundamental devices before processing. Such a process is called "desagering."
Origin
The term “syntactic sugar” was coined by Peter J. Landin in 1964 to describe the surface department of grammar in simple ALGOL, a programming language that was defined semantically in terms of applicative expressions of lambda calculus focused on the lexical replacement of λ with “where”.
More recent programming languages, such as CLU, ML, and Scheme, have expanded the term to denote a derivative in a language that can be defined as syntactic sugar from the perspective of the core of the main constructs. Convenient functions of a higher level can be "disaggregated" and decomposed into a subset. This is, in fact, the usual mathematical practice of constructing from primitives.
Drawing on Landin’s distinction between basic linguistic constructs and syntactic sugar properties, in 1991 Matthias Fellaysen proposed a codification of “expressive power” to fit widespread beliefs in literature. He defined this as "more meaningful" to mean that without the language constructs in question, the program should be completely reorganized.
Known examples of syntactic sugar
In COBOL, many of the intermediate keywords are “sweet,” meaning they can be omitted if desired. For example, the sentence MOVE A B. and MOVE A TO B. perform exactly the same function, but the second makes the action to be performed more clear.
Extended compound assignment operators: for example, a + = b is equivalent to a = a + b in C and similar languages, suggest that a has no side effects, for example, a is a regular if variable.
In Perl, unless (condition) {...}
is syntactically if (not condition) {...}
. In addition, any statement may be followed by the condition that statement if condition
equivalent to if (condition) {statement}
, but the former is more naturally formatted on one line.
In the "C" language, pointers to the beginning of a memory element can be written without using special syntaxes: *(a + i)
. Although there is a special syntax for this process in this language: a [i]. Similarly, a->x
, a record is syntactic sugar for accessing members using the dereference operator (*a). x
(*a). x
.
Using
A statement in C # ensures that some objects are disposed of correctly. The compiler expands the statement into a try-finally block.
C # allows variables to be declared as var x = expr
, which allows the compiler to infer the type x
from the expr
expression, instead of requiring an explicit declaration.
Lists also contain Python syntactic sugar (for example, [x*x for x in range (10)]
for a list of squares) and decorators ( @staticmethod
).
In Haskell, a quoted string is semantically equivalent to the number of characters.
In the rvest package, the designation%>% is found, and indicates that the data (or the output of the function) preceding it will serve as the first argument of the next tool. This provides a more linear flow and data manipulation design. Tidyverse is written to accommodate values.
Criticism
Some programmers believe that these possibilities of using the syntax are either not important or simply not serious. It is noteworthy that special linguistic forms make the language less uniform, and its specification more complex, and can cause problems as programs become larger. This representation is especially widespread in the Lisp community, as it has a very simple, regular, and superficial syntax that can be easily changed.
Derived Terms
Syntactic salt. The metaphor has been expanded to include this term, which refers to a function designed to make writing bad code more difficult. In particular, syntactic salt is a hoop through which programmers must jump to prove that they know what is happening, and not express the action of the program. For example, in Java and Pascal, assigning a floating-point value to a variable declared as int without additional syntax explicitly stating that the intent will result in a compilation error, while C and C ++ automatically truncate all the floating-point numbers assigned to int . However, this is not syntax, but semantics.
In C #, when hiding an inherited member of a class, a compiler warning is issued unless the keyword is used to indicate that the hide is intentional. This is necessary in order to avoid possible errors due to the similarity of the syntax statement switch to the fact that from C or C ++, C # requires a break for each non-empty case of the switch label, even if it does not allow an implicit drop.
The syntactic salt can violate its purpose, making the code unreadable and, thus, degrading its quality. In extreme cases, the main part may be shorter than the overhead introduced to meet the requirements of the language.
An alternative to this concept is the generation of compiler warnings when there is a high probability that the code appears to be the result of a practice error common in modern C / C ++ compilers.
Syntactic saccharin
Another extension is also syrup. Like saccharin, it means an unreasonable syntax that doesn't make programming easier.
It may seem strange to call the language “sweet”, but if you work in Rubyist, it will be justified. This program has more syntactic sugar than in many languages, because it focuses on human understanding, and not on computer. The creator of Ruby, Yukihiro Matsumoto, wanted to make the language not only effective, but also fun. Compilers and interpreters may like such a highly structured, unambiguous division of grammar, but it may be difficult for people to understand it. This is where syntactic sugar appears - it makes the language “sweeter” in both writing and reading.
Code writing
It must be remembered that “syntactic sugar” is not a technical term, but a construct designed to help describe the way a language is expressed. Simply put, this term refers to optimized code for people. The goal is to simplify the syntax so that it is easy to read, even if it reduces some technical clarity. Of course, writing sweet code does not mean that you can skip the important stage of understanding.
As in real life, knowing how much sugar is used is important for overall health. Sugar makes code simple and expressive, but also causes ambiguity. This is usually due to the fact that not everyone knows and applies this concept when programming.