Why are shortcuts like x += y considered good practice?

Question

I have no idea what these are actually called, but I see them all the time. The Python implementation is something like:

x += 5 as a shorthand notation for x = x + 5.

But why is this considered good practice? I've run across it in nearly every book or programming tutorial I've read for Python, C, R so on and so forth. I get that it's convenient, saving 3 keystrokes including spaces. But they always seem to trip me up when I'm reading code, and at least to my mind, make it less readable, not more.

Am I missing some clear and obvious reason these are used all over the place?

Answer 1

It's not a shorthand.

The += symbol appeared in the C language about 20 years ago, and - with the C idea of "smart assembler" correspond to a clearly different machine instruction: += maps to INC, while + maps to ADD.

With a clean idea that the first is operating on x, while the second is evaluating an expression and later place the result in a given place.

Enabling compiler optimization the correspondence can be swapped based on convenience, but there is still a conceptual difference.

x += 5 means

• find the place identified by x
• add 5 to it,

but x = x + 5 means:

• evaluate x+5
  • find the place identified by x
  • copy x into an accumulator
  • add 5 to the accumulator
• store the result in x
  • find the place identified by x
  • copy the accumulator to it.

Of course, optimization can

• if "finding x" has no side effects, the two "finding" can be done once (and x become an address stored in a pointer register)
• the two copy can be elided if the ADD is applied to &x instead to the accumulator

thus making the optimized code to coincide the x += 5 one.

But this can be done only if "finding x" has no side effects, otherwise

*(x()) = *(x()) + 5;

and

*(x()) += 5;

are semantically different, since x() side effects will be produced twice or once.

The equivalence between x = x + y and x += y is hence due to the particular case where += and = are applied to a direct l-value.

---

[EDIT: Following Brendan Comment]

Yes, in the x86 family, ++ maps INC, += maps ADD() and + maps ADD I'm not referring to any specific assembly language, but to an aspect of processors architetcures:

Every CPU has an ALU (aritmetic-logical unit) that is -in its very essence- a combinatorial network whose inputs and output are "plugged" to registry and / or memory depending on the opcode of the instruction

Bynary operation are typically implemented as "modifier of an accumulator register with an input taken "somewere", where somewhere can be - inside the instruction flow itself (typical for manifest contant: ADD A 5) - inside another registry (typycal for expression conputation with temporaries: es ADD A B) - inside the memory, at an address given by a register (typical of data fetching es: ADD A (H)) - H, in this case, work like a dereferencing pointer.

With this pseudocode, x+=5 is

ADD (X) 5

while x = x+5 is

MOVE A (X)
ADD A 5
MOVE (X) A

That is x+5 gives a temporary that is later assigned. x+=5 operates directly on x.

The actual implementation depends on the real instruction set of the processor: If there is no ADD (.) c the first code becomes the second. If there is and optimization are enabled the second code become the first.

Answer 2

Depending on how you think about it, it's actually easier to understand because it's more straightforward. Take, for example:

x = x + 5 invokes the mental processing of "take x, add five to it, and then assign that new value back to x"

x += 5 can be thought of as "increase x by 5"

So, it's not just shorthand, it actually describes the functionality much more directly. When reading through gobs of code, it's much easier to grasp.

Answer 3

It is called an idiom. Programming idioms are useful because they are a consistent way of writing a particular programming construct.

Whenever someone writes x += y you know that x is being incremented by y and not some more complex operation (as a best practice, typically I wouldn't mix more complicated operations and these syntax shorthands). This makes the most sense when incrementing by 1.

Answer 4

To put @Pubby's point a little clearer, consider someObj.foo.bar.func(x, y, z).baz += 5

Without the += operator, there are two ways to go:

1. someObj.foo.bar.func(x, y, z).baz = someObj.foo.bar.func(x, y, z).baz + 5. This is not only awfully redundant and long, it's also slower. Therefore one would have to
2. Use a temporary variable: tmp := someObj.foo.bar.func(x, y, z); tmp.baz = tmp.bar + 5. This is ok, but it's a lot of noise for a simple thing. This is actually really close to what happens at runtime, but it's tedious to write and just using += will shift the work to the compiler/interpreter.

The advantage of += and other such operators is undeniable, while getting used to them is only a matter of time.

Answer 5

At least in Python, x += y and x = x + y can do completely different things.

For example, if we do

a = []
b = a

then a += [3] will result in a == b == [3], while a = a + [3] will result in a == [3] and b == []. That is, += modifies the object in-place (well, it might do, you can define the __iadd__ method to do pretty much anything you like), while = creates a new object and binds the variable to it.

This is very important when doing numerical work with NumPy, as you frequently end up with multiple references to different parts of an array, and it is important to make sure you don't inadvertently modify part of an array that there are other references to, or needlessly copy arrays (which can be very expensive).

Answer 6

While the += notation is idiomatic and shorter, these are not the reasons why it is easier to read. The most important part of reading code is mapping syntax to meaning, and so the closer the syntax matches the programmer's thought processes, the more readable it will be (this is also the reason why boilerplate code is bad: it is not part of the thought process, but still necessary to make the code function). In this case, the thought is "increment variable x by 5", not "let x be the value of x plus 5".

There are other cases where a shorter notation is bad for readability, for example when you use a ternary operator where an if statement would be more appropriate.

Answer 7

Besides readability, they actually do different things:+= doesn't have to evaluate its left operand twice.

For instance, expr = expr + 5 would evalaute expr twice (assuming expr is impure).

Answer 8

It's concise.

It's much shorter to type. It involves less operators. It has less surface area, less opportunity for confusion.

It uses a more specific operator.

This is a contrived example and I'm not sure if actual compilers implement this. x += y actually uses one argument and one operator and modifies x in place. x = x + y could have an intermediate representation of x = z where z is x + y. The latter uses two operators, addition and assignment, and a temporary variable. The single operator makes it super clear that the value side can't be anything other than y and doesn't need to be interpreted. And there could theoretically be some fancy CPU that has a plus-equals operator that runs faster than a plus operator and an assignment operator in series.

Answer 9

It's true that it's shorter and easier, and it's true that it was probably inspired by the underlying assembly language, but the reason it's best practice is that it prevents a whole class of errors, and it makes it easier to review the code and be sure what it does.

With

RidiculouslyComplexName += 1;

Since there's only one variable name involved, you're sure what the statement does.

With RidiculouslyComplexName = RidiculosulyComplexName + 1;

There's always doubt that the two sides are exactly the same. Did you see the bug? It gets even worse when subscripts and qualifiers are present.

Answer 10

It is a nice idiom. Whether it is faster or not depends on the language. In C, it is faster because it translates to an instruction to increase the variable by the right hand side. Modern languages, including Python, Ruby, C, C++ and Java all support the op= syntax. It's compact, and you get used to it quickly. Since you will see it a whole lot in OPC (other peoples' code), you may as well get used to it and use it. Here is what happens in a couple of other languages.

In Python, typing x += 5 still causes the creation of the integer object 1 (although it may be drawn from a pool) and the orphaning of the integer object containing 5.

In Java, it causes a tacit cast to occur. Try typing

int x = 4;
x = x + 5.2  //this causes a compiler error
x += 5.2     // this is not an error; an implicit cast is done.

Answer 11

Operators such as += are very useful when you're using a variable as an accumulator, i.e. a running total:

x += 2;
x += 5;
x -= 3;

Is a lot easier to read than:

x = x + 2;
x = x + 5;
x = x - 3;

In the first case, conceptually, you're modifying the value in x. In the second case, you're computing a new value and assigning it to x each time. And while you'd probably never write code that's quite that simple, the idea remains the same... the focus is on what you're doing to an existing value instead of creating some new value.

Answer 12

For some insight to why these operators are in the 'C-style' languages to begin with, there's this excerpt from K&R 1st Edition (1978), 34 years ago:

Quite apart from conciseness, assignment operators have the advantage that they correspond better to the way people think. We say "add 2 to i" or "increment i by 2," not "take i, add 2, then put the result back in i." Thus i += 2. In addition, for a complicated expression like

yyval[yypv[p3+p4] + yypv[p1+p2]] += 2

the assignment operator makes the code easier to understand, since the reader doesn't have to check painstakingly that two long expressions are indeed the same, or wonder why they're not. And an assignment operator may even help the compiler to produce more efficient code.

I think it's clear from this passage that K&R believed that compound assignment operators helped with code readability.

It's been a long time since K&R wrote that, and a lot of the 'best practices' about how people should write code has changed or evolved since then. But this programmers.stackexchange question is the first time I can recall someone voicing a complaint about the readability of compound assignments, so I wonder if many programmers find them to be a problem? Then again, as I type this the question has 95 upvotes, so maybe people do find them jarring when reading code.

Answer 13

Besides the obvious merits which other people described very well, when you have very long names it is more compact.

  MyVeryVeryVeryVeryVeryLongName += 1;

or

  MyVeryVeryVeryVeryVeryLongName =  MyVeryVeryVeryVeryVeryLongName + 1;

Answer 14

On the other hand it is more readable because it's less to read and removes any kind ambiguity on what variables it is adding on (ie.ab = ad + 1;)

Answer 15

Consider this

(some_object[index])->some_other_object[more] += 5

D0 you really want to write

(some_object[index])->some_other_object[more] = (some_object[index])->some_other_object[more] + 5

Answer 16

It's not a only a good practice, it's better!

 int a = 5;
 a += 5;

The bytecode of this code is:

0:  iconst_5
1:  istore_1
2:  iinc    1, 5

Instead the exploded code of "+=" operator,

int a = 5;
a = a + 5;

is translated by:

0:  iconst_5
1:  istore_1
2:  iload_1
3:  iconst_5
4:  iadd
5:  istore_1

In conclusion, less (byte)code, more speed!

Less (source)code is more readable and it is high maintainable.

Answer 17

I didn't notice anyone mentioning that you eliminate duplication of a reference.

someLongWindedIdentifireName = someLongWindedIdentifireName + 1

has one more chance of typo than it's shorthand version, and the information density is increased without introducing any indirection, so in my book, complexity goes down.

Answer 18

The other answers target the more common cases, but there is another reason: In some programming languages, it can be overloaded; e.g. Scala.

---

Small Scala lesson:

var j = 5 #creates a variable
j += 4    #compiles

val i = 5 #creates a constant
i += 4    #doesn’t compile

---

If a class only defines the + operator, x+=y is indeed a shortcut of x=x+y.

If a class overloads +=, however, they are not:

var a = ""
a += "this works. a now points to a new String"

val b = ""
b += "this doesn’t compile, as b cannot be reassigned"

val c = StringBuffer() #implements +=
c += "this works, as StringBuffer implements “+=(c: String)”"

---

edit: additionally operators + and += are two separate operators (and not only these: +a, ++a, a++, a+b a += b are different operators as well); in languages where operator overloading is available this might create interesting situations. Just as described above - if you'll overload + operator to perform the adding, bear in mind that += will have to be overloaded as well.

Answer 19

I think that, more important than which one you use (x = x + 5 or x += 5) is to pick one and stick with it. Don't mix it up. It can be a little confusing (and annoying) to see both variants multiple times in the same method/function.

Answer 20

It is shorter.

I don't mean by typed letters (shorter names are not good style), but by count of instructions. The reason for this to be better is the number of possible failures.

If you change x in x = x + 5; you must make sure, that you change both x, while you have to change only one in x += 5;. Though it doesn't look much in this example, it's good practice and with it good style. (If you have your doubts think of

MaxLabelsPerSheet = MaxLablesPerSheet + 5;

instead).

Answer 21

Say it once and only once: in x = x + 1, I say 'x' twice.

But do not ever write, 'a = b +=1' or we will have to kill 10 kittens, 27 mice, a dog and a hamster.

Some people argue that you should never change the value of a variable, as it makes it easier to prove the code is correct.

Answer 22

It's actually faster way to add. Here are the methods of incrementing, ordered by fastest to slowest:

$i += 1;
++$i;
$i++;
$i = $i + 1;