Why avoid increment ("++") and decrement ("--") operators in JavaScript?

Question

I'm a big fan of Douglas Crockford's writing on JavaScript, particularly his book JavaScript: The Good Parts. It's made me a better JavaScript programmer and a better programmer in general. One of his tips for his jslint tool is this :

++ and --
The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. There is a plusplus option that prohibits the use of these operators.

This has always struck my gut as "yes, that makes sense," but has annoyed me when I've needed a looping condition and can't figure out a better way to control the loop than a while( a < 10 )do { a++ } or for (var i=0;i<10;i++) { } and use jslint. It's challenged me to write it differently. I also know in the distant past using things, in say PHP like $foo[$bar++] has gotten me in trouble with off-by-one errors.

Are there C-like languages or other languages with similarities that that lack the "++" and "--" syntax or handle it differently?

Are there other rationales for avoiding "++" and "--" that I might be missing?

---

UPDATE -- April 9, 2010:

In the video Crockford on JavaScript -- Part 5: The End of All Things, Douglas Crockford addresses the ++ issue more directly and with more detail. It appears at 1:09:00 in the timeline. Worth a watch.

Answer 1

The "pre" and "post" nature of increment and decrement operators can tend to be confusing for those who are not familiar with them; that's one way in which they can be tricky.

Answer 2

I'm frankly confused by that advice. Part of me wonders if it has more to do with a lack of experience (perceived or actual) with javascript coders. I can see how someone just "hacking" away at some sample code could make an innocent mistake with ++ and --, but I don't see why an experienced professional would avoid them.

Answer 3

Is Fortran a C-like language? It has neither ++ nor --. Here is how you write a loop:

     integer i, n, sum

      sum = 0
      do 10 i = 1, n
         sum = sum + i
         write(*,*) 'i =', i
         write(*,*) 'sum =', sum
  10  continue

The index element i is incremented by the language rules each time through the loop. If you want to increment by something other than 1, count backwards by two for instance, the syntax is ...

      integer i

      do 20 i = 10, 1, -2
         write(*,*) 'i =', i
  20  continue

Is Python C-like? It uses range and list comprehensions and other syntaxes to bypass the need for incrementing an index:

print range(10,1,-2) # prints [10,8.6.4.2]
[x*x for x in range(1,10)] # returns [1,4,9,16 ... ]

So based on this rudimentary exploration of exactly two alternatives, language designers may avoid ++ and -- by anticipating use cases and providing an alternate syntax.

Are Fortran and Python notably less of a bug magnet than procedural languages which have ++ and --? I have no evidence.

I claim that Fortran and Python are C-like because I have never met someone fluent in C who could not with 90% accuracy guess correctly the intent of non-obfuscated Fortran or Python.

Answer 4

There is a history in C of doing things like:

while (*a++ = *b++);

to copy a string, perhaps this is the source of the excessive trickery he is referring to.

And there's always the question of what

++i = i++;

or

i = i++ + ++i;

actually do. It's defined in some languages, and in other's there's no guarantee what will happen.

Those examples aside, I don't think there's anything more idiomatic than a for loop that uses ++ to increment. In some cases you could get away with a foreach loop, or a while loop that checked a different condtion. But contorting your code to try and avoid using incrementing is rediculous.

Answer 5

My view is to always use ++ and -- by themselves on a single line, as in:

i++;
array[i] = foo;

instead of

array[++i] = foo;

Anything beyond that can be confusing to some programmers and is just not worth it in my view. For loops are an exception, as the use of the increment operator is idiomatic and thus always clear.

Answer 6

Consider the following code

 int a[10];
 a[0] = 0;
 a[1] = 0;
 a[2] = 0;
 a[3] = 0;
 int i = 0;
 a[i++] = i++;
 a[i++] = i++;
 a[i++] = i++;

since i++ gets evaluated twice the output is (from vs2005 debugger)

 [0] 0 int
 [1] 0 int
 [2] 2 int
 [3] 0 int
 [4] 4 int

Now consider the following code :

 int a[10];
 a[0] = 0;
 a[1] = 0;
 a[2] = 0;
 a[3] = 0;
 int i = 0;
 a[++i] = ++i;
 a[++i] = ++i;
 a[++i] = ++i;

Notice that the output is the same. Now you might think that ++i and i++ are the same. They are not

 [0] 0 int
 [1] 0 int
 [2] 2 int
 [3] 0 int
 [4] 4 int

Finally consider this code

 int a[10];
 a[0] = 0;
 a[1] = 0;
 a[2] = 0;
 a[3] = 0;
 int i = 0;
 a[++i] = i++;
 a[++i] = i++;
 a[++i] = i++;

The output is now :

 [0] 0 int
 [1] 1 int
 [2] 0 int
 [3] 3 int
 [4] 0 int
 [5] 5 int

So they are not the same, mixing both result in not so intuitive behavior. I think that for loops are ok with ++, but watch out when you have multiple ++ symbols on the same line or same instruction

Answer 7

If you read JavaScript The Good Parts, you'll see that Crockford's replacement for i++ in a for loop is i+=1 (not i=i+1). That's pretty clean and readable, and is less likely to morph into something "tricky."

Crockford made disallowing autoincrement and autodecrement an option in jsLint. You choose whether to follow the advice or not.

My own personal rule is to not do anything combined with autoincrement or autodecrement.

I've learned from years of experience in C that I don't get buffer overruns (or array index out of bounds) if I keep use of it simple. But I've discovered that I do get buffer overruns if I fall into the "excessively tricky" practice of doing other things in the same statement.

So, for my own rules, the use of i++ as the increment in a for loop is fine.

Answer 8

I don't know if this was part of his reasoning, but if you use a poorly-written minification program, it could turn x++ + y into x+++y. But then again, a poorly written tool can wreak all kinds of havoc.

Answer 9

I've been watching Douglas Crockford's video on this and his explanation for not using increment and decrement is that 1. Is has been used in the past in other languages to break the bounds of arrays and cause all manners of badness and 2. That it is more confusing and inexperienced JS developers don't know exactly what it does.

Firstly arrays in JavaScript are dynamically sized and so, forgive me if I'm wrong, it is not possible to break the bounds of an array and access data that shouldn't be accessed using this method in JavaScript.

Secondly, should we avoid things that are complicated, surely the problem is not that we have this facility but the problem is that there are developers out there that claim to do JavaScript but don't know how these operators work?? It is simple enough. value++, give me the current value and after the expression add one to it, ++value, increment the value before giving me it.

Expressions like a ++ + ++ b, are simple to work out if you just remember the above.

var a = 1, b = 1, c;
c = a ++ + ++ b;
// c = 1 + 2 = 3; 
// a = 2 (equals two after the expression is finished);
// b = 2;

I suppose you've just got to remember who has to read through the code, if you have a team that knows JS inside out then you don't need to worry. If not then comment it, write it differently, etc. Do what you got to do. I don't think increment and decrement is inherently bad or bug generating, or vulnerability creating, maybe just less readable depending on your audience.

Btw, I think Douglas Crockford is a legend anyway, but I think he's caused a lot of scare over an operator that didn't deserve it.

I live to be proven wrong though...

Answer 10

I think programmers should be competent in the language they are using; use it clearly; and use it well. I don't think they should artificially cripple the language they are using. I speak from experience. I once worked literally next door to a Cobol shop where they didn't use ELSE 'because it was too complicated'. Reductio ad absurdam.