# Teaching syntactic sugar

When I show my code to students I tutor, they ask about "all those things in my code", which refers (quite vaguely) to things such as shortened ifs, post\preincrement etc.

They are confused by these things, but once I explain those things, I see that the students constantly use them (not in excess).

This got me wondering what are some of the benefits of teaching syntactic sugar during regular teaching (as part of the lesson plans in the curriculum). What might the students gain from learning syntactic sugar during lessons?

Examples of things I had in mind:

int x;
if(condition){
x=5;
} else{
x=2;
}


is identical to:

int x = condition ? 5 : 2;


Also:

int epoch = 0;

do{
someEpochDepenentOperation(epoch,x);
} while(++epoch < 100);


would be:

int epoch = 0;

do{
someEpochDepenentOperation(epoch,x);
epoch++;
} while(epoch < 100);

• I think it's typical when teaching abbreviations to show the non abbreviated version too. Jul 23, 2017 at 19:07
• @EllenSpertus so I should show both? Jul 23, 2017 at 19:07
• For the 2nd example I would go with a for loop. Jul 23, 2017 at 19:14
• Yes, show both at first. Jul 23, 2017 at 19:22
• As an "old timer" I cannot let any mention of "syntactic sugar" in Java/C++ pass without quoting Alan Perlis: "Syntactic sugar causes cancer of the semicolon." To see all his wonderful epigrams, follow leptonica.com/cachedpages/perlis-epigrams.html Jul 24, 2017 at 15:41

The ?: operator is not syntactic sugar (OK in most languages it is, and no guarantees/checks are made). It is a different construct.

if predicate then action1 else action2 is procedural

predicate ? value1 : value1 or value1 if predicate else value2 is functional

The first does something, the second evaluates to something. The value is that the functional form tells you that you are doing something functional, that there are no side effects. Thus making the code easier to read (once you have the vocabulary).

In this example

int x;
if(condition){
x=5;
} else{
x=2;
}


the reader must ask, can x remain uninitialized? What are all the values that x can take? Does anything else change or happen?

Where as for this example

int x = condition ? 5 : 2;


We see that we initialize x, to 5 or 2. That is it. We could also write

const int x = condition ? 5 : 2;


This tells us that x is x: it never changes.

• @richard As I understand, there is no such guarantee, at least in Java: x = truefalse() ? badSideEffectMethod1() : badSideEffectMethod2();
– Ben I.
Jul 23, 2017 at 19:12
• Actually, evaluating the predicate or subepressions may have side effects. The difference is whether statements can go in the arms, for languages where statements and expressions differ. Jul 23, 2017 at 19:14
• @BenI. What do you mean by "no guarantee"? I didn't fully understand. Jul 23, 2017 at 19:15
• I thought I understood until @EllenSpertus said what she just said. Let's move this conversation to chat?
– Ben I.
Jul 23, 2017 at 19:17
• The compiler (java, C#, C++ etc) does not check that each of the terms are pure functions (have no side effect). Jul 23, 2017 at 19:17

Generally I feel one element should be core when it comes to this and that is readability. From my own experience when I was just starting off with programming I'd always explicitly define my scopes. That is to say every if opens with a condition, followed by an encapsulated (series of) statement(s).

The point for me back then was to get rid of ambiguity when you aren't experienced in recognizing scope and the flow of code.

So I feel that at first you should try and teach your students a very clear and obvious way of coding. Ternary operations (i.e. the ? operator) tend to be hard to grasp when inexperienced, so try and stick to always start from the more explicit code, and then as you come across your N'th if statement in your example you show them alternatives. That way, you'll let them know you can make the code more interesting, without pushing them to do so and get confused in all the options there are.

Then when they get more comfortable and experienced I feel you should slowly make your code more and more implicit and add some more sugar to it. That way you can be sure that once you explain it, everyone will get it fairly quickly, and it gives them the freedom appropriate for their skill level.

The point here being that you want to let your students know you can do these things but advice them to get the basics down first. Then after repetition, and you yourself steering more to actual proper code, I reckon many students will pick and choose what they themselves are most comfortable with, which you can use to actually understand and support them better as well.

So, think of it as an inverse funnel, you start them off straight and reliable, and as they learn more and more, you give them more options and freedom.

While I agree with this answer that the conditional expression is more than just sugar, I think the following consideration is important in many languages:

While the student can be led to always writing with a consistent and clear style that avoids tricks and obfuscations, he/she will also need to be able to read code of others who take less care. So, especially in a language like Perl, which seemingly has an endless number of ways to do things, being able to read may be as important as being able to write.

After all, the text of a program is normally read more often by humans than by computers, especially if the program is important.

That is all the more reason to develop a good style, but also shows why the less-explored corners of the language need light shed on them.

Note that in some organizations, not using an approved style will (WILL) get you reprimanded. Some might treat the idea that you should fully brace every compound statement (if, while,...) in Java as syntactic sugar, but I treat it as essential.

Moreover, some things that look like syntactic sugar are really well developed idiom in that language.