X += x++

This is essentially a small piece out of a much bigger pie, which is that if you program in languages that allow you to be 'clever' you should use a 'safe subset' of that language where behaviour is both unambiguous and the same across all platforms. This will save you a lot of headaches debugging a program that works fine on a different installation.<p>There are many other examples of this, for instance always use 'sizeof()' even if you know your storage allocation units, don't rely on the byte order of your words (endian-ness), stick to <i>one</i> statement (explicit or implicit, the example line from the article has two statements).<p>What makes the example so tricky is that you have to know the innards of the compiler (or at least of the expression evaluator) to be able to correctly predict what that code will do.<p>Some people think there are bonus points to be had for such 'cleverness' because you only need one line where someone else needs two. There isn't and all it will give you (or, possibly your successor) is a bunch of extra gray hairs.<p>A similar case can be made for always using brackets, even when they're optional, not using assignments in condtionals and so on.<p>It's the kind of thing where a junior programmer will go 'oh, cool!', and a seasoned one will go 'oh oh'.<p>In the case of complicated expressions feel free to add some extra parentheses to make the order of evaluation implicit. They don't cost you anything and they'll allow someone else to read the expression from the inside to the outside instead of from the left to the right and then apply the order-of-evaluation rules.<p>If you come across:<p><pre><code> x = y + z*a + b*d^i++; </code></pre> And you think it does the same as:<p><pre><code> x = y + (z*a) + (b*(d^i)) ; i++; </code></pre> Then think again, it is equivalent to:<p><pre><code> x = (y + (z * a) + (b*d))^i); i++; </code></pre> There is absolutely no penalty for writing it down explicitly.<p>Sure, some seasoned old hand is going to say, hey, don't you know the expression evaluation rules by heart ? But don't let that intimidate you, that's probably also the person that spends a lot of time in the debugger fixing their extreme cleverness.<p>The compiler will generate exactly the same code for either the first or the last example (but <i>not</i> the second), there really is 0 penalty, use that.

I don't know as much about C# as I do C or C++ but they both have the concept of sequence points in between which order of operations is undefined behavior. As such I find his specification of order of ops suspicious and makes a stronger argument for explicit statements. However the whole if you don't know what it does then you should be learning not dumbing down the rest of us should apply.