Monday, July 19, 2021

Pluses and Minuses of the Unary increment Operator

There has been a conversation on Twitter about the unary increment operator (++) and related (+=, –, etc.). I tend to gloss over these when teaching beginners. Especially those in a first programming course. A friend of mine disagrees. It started with:

Would you ever write, or teach a beginner, a = a + 1 if your language supports a += 1 If so, why?

Now obviously professional programming and beginner programming are not exactly apples and apples but we should probably be teaching best practices. Right? On the other hand, there is thing called cognitive load. There are really  at least four ways (in most C-style languages) to ad one to a variable.

  1. a = a + 1
  2. a += 1
  3. a++
  4. ++a

I generally teach options 1 and 3. I mention the others but don’t really expect students in a first class to use them all. Cognitive load. It’s enough for students to remember two ways to do something and they don’t need all four.

The first one has an advantage that it follows a general form. A value is added to a variable and saved in the original variable. This works for a lot more than adding one. Now arguably a += 1  does the same thing but the other format is a building block for more complicated  assignments with out the complexity of figuring out where += fits into the order of operations.

Now the pre and post increment (and decrement) operators are sort of special. It makes a difference which one you use;

foo = bar[I++] and foo = bar[++I] give very different results.

Personally I don’t want beginners using either except as a standalone statement. So I teach it for incrementing loop control values but don’t talk much about using it other places. Now obviously there are cases when using these operators in other places is a good idea. But I think beginners have enough trouble as it is without adding some unneeded complexity.

As time goes on and students become more comfortable with the language and the art of programming, by all means, show them the cool stuff. But remember that code should be readable by people as well as computers. When I was doing code reviews as a professional developer I always looked to readable and easy to maintain code. That’s how I want my students thinking as well.

Agree? Disagree? Jump in in the comments below.

4 comments:

  1. I do much as you do - teach and encourage i=i+1 most of the time but consider i++ or ++i acceptable as standalone constructs.

    I always used to write i++ but have been seeing ++i more and more these days - ++i probably makes more sense. I don't know any stats but it seems to me to be more intuitive what it does as opposed to i++.

    ReplyDelete
  2. a=a+1 works in every language I teach. The other forms are dependent. I point them out to the kids but rarely actually use or teach them. I know a=a+1 works and requires no thinking. I like things with no thinking.

    ReplyDelete
  3. I agree with the others. a=a+1 is just fine for everything. Very true about cognitive load for your students.

    And I think that is just fine in a professional environment as well. It seems to lead down that road of ever increasing density of code. When someone says the can rewrite a section of code in one or two lines I always say that I don't want to be the person maintaining that code in a few years.

    ReplyDelete
  4. Somewhat related to the cognitive load point, a = a + 1 most clearly exemplifies the "=" symbol as an assignment operator, which is itself a bit odd at first for some students. It's not uncommon for some to reverse the order at first, writing a + 1 = a. (Some days I miss APL's <- assignment operator!)

    I stick with the traditional at least until everyone gets assignment figured out, and then introduce the other variations in Python and Java classes.

    I studiously avoid ++a.:)

    ReplyDelete