Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking at a programming language design decision that's difficult to make precisely because there seems to be no objective basis for choosing one option over the other. The question is, given that a language doesn't have a ++ operator, would the better choice for an increment operator be as in C:

a += 1
a += b

or as in some versions of Pascal:

inc a
inc a b

(And similarly with -= vs dec of course.)

Considerations I can see for inc:

  • Slightly shorter for the typical case where the delta is 1.
  • Less familiar to most programmers.
  • Eliminates the corresponding *= etc operators, which are much less commonly used.

Is there anything I'm missing?

share|improve this question
At least in the pascal dialect I know best, those two aren't built into the language but simple pass-by-reference functions (procedure inc(x: var Integer); begin x := x + 1 end or something like that). So simplicity at language level may be another point. – delnan Jan 7 '12 at 11:02
It depends on the rest of the language. For instance could +=also mean string concatenation and would this cause users to get undesired results like it can in javascript. – WuHoUnited Jan 7 '12 at 14:13
up vote 8 down vote accepted

I think inc and dec are a poor choice, for the following reasons:

  • They are abbreviations and abbreviations should be avoided. At the same time increase and decrease would be a lot to write.
  • They introduce extra keywords. A language should have as few keywords as possible, so that programmers are as free as possible in their choice of names.
  • inc a b is a binary prefix operator. In C-style-ish languages, almost all binary operators are all infix (except array access).
  • Unlike += and -= they don't emerge from a rule, but are arbitrarily chosen. Once you understand that L o= E means L = L o E, you can use this with any operator. Personally I use *= and /= quite often (scale up, scale down), as well as ||= (set if null (this actually depends on the language)), &&= (good for aggregating conditions).

That last point is the most important one. When designing a language, you want few features that compose well rather than having a lot of idiosyncracies to be memorized.
Your language has "pure" binary operations and assignments. And anyone can write a = a o b already (thus explicitly composing assignment and the binary operator o). Adding inc and dec and whatnot to the cocktail is not good, because it is a non-evident choice, that covers a single case.
As a counter example: adding call by reference for example allows programmers to roll their own inc if it pleases them. That's a powerful feature. Similarly, allowing the combination of any binary operator with an assignment operator also composes well, because it works with any operator.

share|improve this answer
+1. I also use |= (set bit) and &= (reset bit). – MSalters Jan 9 '12 at 12:59
Yeah, you're right. The deciding factor was running some searches over the ten million lines or so of the Linux kernel, and finding in that kind of systems code, operators like |= are actually used very frequently. – rwallace Jan 13 '12 at 21:58

As in other domains, the primary consideration should be given to the users of the language and their needs and habits. Principle of least surprise suggests that the preference should be given to the choice which is consistent with your users' current habits, i.e. if they're primarily C, C++, Java or Python programmers, += is a better choice.

share|improve this answer

I think that += is more universal, since you can extend it to other operations as well without having to introduce new keywords:

*=, &=, |= and more...

It is no problem to introduce a new operator like *= later, but introducing new keywords is problematic, since they can conflict with identifiers in existing code.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.