<p>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 <strong>encapsulated</strong> (series of) statement(s).</p>

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

<p>So I feel that <strong>at first</strong> 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 <strong>start from</strong> 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.</p>

<p>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.</p>

<p>The point here being that you want to let your students know you <strong>can</strong> 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.</p>

<p><strong>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.</strong></p>

CC BY-SA 3.0
2017-07-31T13:42:36.387Z
2017-07-31T13:42:36.387Z
SpiritBH
<p>While I agree with <a href="https://cseducators.stackexchange.com/a/2880/1293">this answer</a> that the conditional expression is more than just sugar, I think the following consideration is important in many languages: </p>

<p>While the student can be led to always <em>writing</em> 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. </p>

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

<p>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. </p>

<p>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. </p>

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

CC BY-SA 3.0
2017-07-31T14:42:58.077Z
2017-07-31T14:42:58.077Z
Buffy
<p>The ?: operator is not syntactic sugar (OK in most languages it is, and no guarantees/checks are made). It is a different construct. </p>

<p><code>if predicate then action1 else action2</code> is procedural</p>

<p><code>predicate ? value1 : value1</code> or <code>value1 if predicate else value2</code> is functional</p>

<p>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).</p>

<p>In this example</p>

<pre><code>int x;
if(condition){
    x=5;
} else{
    x=2;
}
</code></pre>

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

<p>Where as for this example</p>

<pre><code>int x = condition ? 5 : 2;
</code></pre>

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

<pre><code>const int x = condition ? 5 : 2;
</code></pre>

<p>This tells us that x is x: it never changes.</p>

CC BY-SA 3.0
2017-07-23T19:12:46.117Z
@richard As I understand, there is no such guarantee, at least in Java: `x = truefalse() ? badSideEffectMethod1() : badSideEffectMethod2();`
Ben I.
CC BY-SA 3.0
2017-07-23T19:14:05.123Z
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.
Ellen Spertus
CC BY-SA 3.0
2017-07-23T19:15:59.897Z
@BenI. What do you mean by "no guarantee"? I didn't fully understand.
ItamarG3
CC BY-SA 3.0
2017-07-23T19:17:27.700Z
I thought I understood until @EllenSpertus said what she just said.  Let's move this conversation to [chat](https://chat.stackexchange.com/rooms/59174/the-classroom)?
Ben I.
CC BY-SA 3.0
2017-07-23T19:17:27.910Z
The compiler (java, C#, C++ etc) does not check that each of the terms are pure functions (have no side effect).
ctrl-alt-delor
CC BY-SA 3.0
2017-07-23T19:06:49.703Z
2017-07-23T19:16:03.863Z
2017-07-23T19:16:03.863Z
ctrl-alt-delor
<p>When I show my code to students I tutor, they ask about <em>"all those things in my code"</em>, which refers (quite vaguely) to things such as shortened <code>if</code>s, post\preincrement etc.</p>

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

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

<p>Examples of things I had in mind:</p>

<pre><code>int x;
if(condition){
    x=5;
} else{
    x=2;
}
</code></pre>

<p>is identical to:</p>

<pre><code>int x = condition ? 5 : 2;
</code></pre>

<p>Also:</p>

<pre><code>int epoch = 0;

do{
    someEpochDepenentOperation(epoch,x);
} while(++epoch &lt; 100);
</code></pre>

<p>would be:</p>

<pre><code>int epoch = 0;

do{
    someEpochDepenentOperation(epoch,x);
    epoch++;
} while(epoch &lt; 100);
</code></pre>

CC BY-SA 3.0
2017-07-23T19:07:23.947Z
I think it's typical when teaching abbreviations to show the non abbreviated version too.
Ellen Spertus
CC BY-SA 3.0
2017-07-23T19:07:58.373Z
@EllenSpertus so I should show both?
ItamarG3
CC BY-SA 3.0
2017-07-23T19:14:17.353Z
For the 2nd example I would go with a `for` loop.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-23T19:14:46.477Z
@richard fair point.
ItamarG3
CC BY-SA 3.0
2017-07-23T19:22:45.447Z
Yes, show both at first.
Ellen Spertus
CC BY-SA 3.0
2017-07-24T15:41:20.857Z
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 http://www.leptonica.com/cachedpages/perlis-epigrams.html
Richard Pattis
CC BY-SA 3.0
2017-08-02T15:50:09.383Z
@RichardPattis I see you have quite a collection of epigrams at your website, as well as being a CS luminary. (I recognized your name but had to Google you to recall your claims to fame, such as being the creator of the Karel programming language.)
Ellen Spertus
<curriculum-design><secondary-education><syntax>
Teaching syntactic sugar
# Teaching syntactic sugar

(Asked by: username_0 on 2017-07-23)

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);

**Tags:** curriculum-design, secondary-education, syntax

> **Comments:**
> **username_1**: I think it's typical when teaching abbreviations to show the non abbreviated version too.  
> **username_0**: @EllenSpertus so I should show both?  
> **username_2**: For the 2nd example I would go with a `for` loop.  
> **username_0**: @richard fair point.  
> **username_1**: Yes, show both at first.  
> **username_3**: 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 http://www.leptonica.com/cachedpages/perlis-epigrams.html  
> **username_1**: @RichardPattis I see you have quite a collection of epigrams at your website, as well as being a CS luminary. (I recognized your name but had to Google you to recall your claims to fame, such as being the creator of the Karel programming language.)  

---

## 3 answers

### Answer by username_2 on 2017-07-23. Score: 3

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.

> **Comments:**
> **username_6**: @richard As I understand, there is no such guarantee, at least in Java: `x = truefalse() ? badSideEffectMethod1() : badSideEffectMethod2();`  
> **username_1**: 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.  
> **username_0**: @BenI. What do you mean by "no guarantee"? I didn't fully understand.  
> **username_6**: I thought I understood until @EllenSpertus said what she just said.  Let's move this conversation to [chat](https://chat.stackexchange.com/rooms/59174/the-classroom)?  
> **username_2**: The compiler (java, C#, C++ etc) does not check that each of the terms are pure functions (have no side effect).  

---

### Answer by username_4 on 2017-07-31. Score: 2

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.**


---

### Answer by username_5 on 2017-07-31. Score: 2

While I agree with [this answer](https://cseducators.stackexchange.com/a/2880/1293) 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.


---

