Prefix vs Postfix When Using Increment & Decrement Operators.

Cover photo: @markusspiske

Whether you've been using JavaScript for 10 days or 10 years, you've most certainly come across and have used the increment (++) and decrement (--) operators.

But were you aware that how you use these on the operand will differ when used prefixed as opposed to postfixed?

The Difference

First, let's see what happens when we use a postfixed increment operator.

Given this statement, what would you expect the console to log?

let count = 0
console.log(count++)
console.log(count)

You may have been expecting it to log 1 for both, but this isn't the case. It will log 0 and then 1.

let count = 0
console.log(count++) // 0
console.log(count) // 1

Why? Because postfixed operators will return the value of the operand before applying the operator.

Now, let's try the exact same code, but with a prefixed operator:

let count = 0
console.log(++count) // 1
console.log(count) // 1

As you can see, the operator is now first applied and then the value is returned after.

Conclusion

So what's the take away here? I think really just to be aware of the intricacies of JavaScript. There's no harm in using these operators, but you should be aware of how it will affect your code. Sometimes it can even be better to go the explicit route: count = count+1.

Either way, I hope you learned something!

As always,
Happy Coding 🤓

Comments

[Kevin Sullivan]

const inc = num => num + 1 FTW!

[Michiel Hendriks]

I alway use the prefix version, because it only does two things instead of three, and thereby more correct.

[Caleb Rudder]

Depending on the situation, I'm not sure that less steps explicitly means more correct. Maybe more efficient, but even then I'm sure that's arguable depending on what the steps are.

Could you provide an example of how less steps explicitly makes a calculation more correct? I'm genuinely curious

[Michiel Hendriks]

It has nothing to do with number of steps, or more efficient (although ++i is more efficient than i++ in non-optimizing compilers).

It is a simplicity principle. This principle is the foundation of a lot of other philosophies and theories. For example, in the UNIX philosophy "Make each program do one thing well.". Or the simple statement "less is more".

Constructions which require less cognitive effort are easier to work with, and therefor result in less mistakes. This article basically point this out. So, both constructions can be correct, but the one which requires less cognitive effort is more correct.

A simple example.

int i = 0
do {
    print "hello"
    i++
} while (i < 10)

Let's refactor that

int i = 0
do {
    print "hello"
} while (i++ < 10)

Guess what, now it's wrong.

[Caleb Rudder]

Adding in the simplicity principle makes a lot of sense. In your original comment I was confused by the correlation of less steps and how correct a function is.

"the one which requires less cognitive effort is more correct."

This statement is what really answered my question. Thanks for taking the time to explain! That actually helped me better understand the simplicity principle better.

[Michiel Hendriks]

Bjarne Stroustrup was also fooled by the postfix incrementor

Tim Sweeney

@timsweeneyepic

The funny thing about C++ is that it should update C to be the successor language, but return the original version of C.

01:31 AM - 13 Jan 2019

33 198