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

For loops are usually inclusice, exclusive, meaning that you start at the bottom, and stops when you reach, but don't to the top. In Python:

for i in range(0,a):

would print 0 through a-1. The same applies for Java:

for(int i = 0; i < a; i++){

would also print 0 through a-1, allthough the syntax is somewhat clearer.

So what if you want to print every number up to a, inclusive? Would you write

for(int i = 0; i <= a; i++){


for(int i = 0; i < a + 1; i++){

I guess the first makes the most sense, you're looping while i is less or equals to a, but the less than sign could easily be overlooked. The a + 1 isn't that easy to miss, in my opinion.

So my question is: Is there a better alternative of the two, and is there a convension for this thing?

I just want to point out that i'm talking about integers here.

share|improve this question

closed as primarily opinion-based by Dan Pichelman, ThinkingMedia, MichaelT, GlenH7, gnat Sep 18 '13 at 3:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

should that be "i < a + 1" in the second code sample? – cdkMoose Sep 17 '13 at 21:21
"Better" is probably not what you're looking for. There won't be a measurable performance difference. "Clearer" would be a better choice. – Bobson Sep 17 '13 at 21:25
Well, I never said anything about better being faster, did I? Clearer would probably be a better word, though. – MartinHaTh Sep 17 '13 at 21:34
a <= b is not necessary the same as a < b + 1 if we are not constrained to integers (and I'm ignoring operator overloading and overflow as well). You may want to clarify the data types. Example: 1.1 <= 1 is false, but 1.1 < 1 + 1 is true. – Thomas Eding Sep 17 '13 at 22:34
I disagree with the [On hold] status of this question. It is not opinion-based, it is experience-based. And indeed provided answers express expertise rather than opinion. – mouviciel Sep 18 '13 at 5:34
up vote 11 down vote accepted

Say what you mean.

If you mean that the loop should run while the index variable is less than or equal to a, say that.

the less than sign could easily be overlooked

The <= operator is very common, particularly in loops. Trust your audience to be able to correctly read correctly written code. Don't avoid the natural solution simply because of a perceived possibility that some unknown future reader might need to get their eyes checked.

The a + 1 isn't that easy to miss

It's not that easy to understand, either. What would you think if you saw the code that you're proposing? I'm pretty sure I'd think something like:

Why are we talking about a + 1 when the loop obviously should run up to a? Oh, wait... I'm looking through the code, and this guy seems to have a phobia about <=... It doesn't appear anywhere in the code, and I see a few places where he goes out of his way to avoid it...

For loops are usually inclusice, exclusive

That assumption is incorrect. For loops continue while the looping condition is true.

The Python example you give is "inclusive, exclusive" only because Python's range(0,a) happens to generate the list 0..a-1. The whole "inclusive, exclusive" idea is a red herring -- it only applies because range() happens to work that way.

You could easily write your own range-like function that returned 0..a inclusive and use that to control your loop. Or you could supply your own list instead of relying on range() to generate the list:

list = [1, 2, 3]
for i in list

In this case the loop will execute three times, once for each value in list. In other words, it's not the for loop that's excluding a in your example, but rather range().

share|improve this answer
When saying that <= is easier to read, aren't you also implying that the i < a + 1 isn't really good for anything? I can't come up with an example where you would need to loop until, exclusive, i reaches a + 1 – MartinHaTh Sep 17 '13 at 22:03
@MartinHaTh I suppose you'd need it if i were a float and you wanted to allow values in the range [a..a+1), but I don't see the need simply to avoid <=. On the other hand, if one needs to write i < a + 1, that must mean that <= is sufficiently hard to read/understand that we should take pains to avoid it, and I don't believe that's true. – Caleb Sep 17 '13 at 22:15
"the second parameter to range() isn't an upper bound, it's the number of values to generate". This is incorrect. The second parameter to range most definitely is an upper bound. Try range(5,10), for example. – John Bartholomew Sep 17 '13 at 22:44
@JohnBartholomew Thanks for that -- you're right, of course, and I should have known that from the name. I'll correct that now. – Caleb Sep 17 '13 at 23:17

The best convention is readability: Write code as close to your intent as possible.

If you mean: i should be less than or equal to a, then write i <= a.

If you mean: i should be less than a+1, then write i < a+1.

share|improve this answer
Could you come up with an example for each? I'm having a problem doing so. They are the same, after all. – MartinHaTh Sep 17 '13 at 21:36
They are only the same in the case of ints. In the case of real numbers they are not the same and if in the future the increment changes to something like 0.5, one of these two expressions would be incorrect. So always write as close to what you mean as possible. – Stephen Sep 17 '13 at 23:10
@MartinHaTh: Think of it this way, when enumerating an array is it easier to read i < length or i <= length - 1. The former is more readable because you know that the index has to be less than the length. Similarly if you have an inclusive end-point (as in your example) we typically think of it inclusively, making the <= notation more readable. – Guvante Sep 17 '13 at 23:14
Both may be mathematically true, but one may be more correct at a casual level. If the problem specification says "The value must be no more than the threshold", i <= a best captures the concept, even though i < a+1 would also work. – Ross Patterson Sep 17 '13 at 23:15
Language conventions are critical to readability. In C/C++/Java, a loop with <= is almost always wrong. In Pascal, a loop will usually have <= .... – mattnz Sep 18 '13 at 3:24

Less than or equal is 1 assembler instruction.

a <= b

On the X86 family of processors the above would be something like:

MOV EAX, _a_
CMP EAX, _b_
JLE _label_

Less than or b plus 1 is two extra assembler instructions.

a < b+1

Whereas, the above would be something like:

MOV ECX, _a_
MOV EDX, _b_
JL _label_

To argue that one method is more readable than another is simply silly. They are both equally readable, but <= should be the standard. Anyone doing b+1 is unnecessarily adding extra tasks for the language to perform. It doesn't matter if it's Java, C#, C++ or PHP because you're telling it to perform an unnecessary addition. If you're lucky the compiler you're using will optimize this out.

Someone answered:

If you mean: i should be less than or equal to a, then write i <= a.

If you mean: i should be less than a+1, then write i < a+1.

That makes no senses at all, because the two mean exactly the same thing. The correct answer is less than or equal. The easiest to read math expression is always the simplest i <= a.

share|improve this answer
i <= a and i < a + 1 only mean the same thing because the OP is talking about integers. Even in that case the latter obfuscates the intent, which is of course i <= a. – Caleb Sep 17 '13 at 23:41
I'm guessing that if the data type is in fact an integer, almost every compiler/jitter would optimize this out. You'd have to incredibly unlucky for it to have any noticeable impact. Unless you're writing C code for an embedded RTOS, it's not worth worrying about micro-optimization like this. – Aaronaught Sep 18 '13 at 1:09
-1 For the presumptuous premature optimisation and x86 assembler, neither were mentioned by the OP. Engineering time cost exceeded hardware cost for a vast majority of software about 30 years ago. – mattnz Sep 18 '13 at 3:21
I disagree that they're equally readable. If I see a + 1 in an expression, I'm going to assume that there is something significant about the value a + 1. In this case, there isn't, and my assumption is incorrect. Expressing the loop as i < a + 1 is not commonplace behaviour and is distracting. It violates the principle of least astonishment. – Carson63000 Sep 18 '13 at 4:32
@MathewFoscarini - I certainly don't find i < a + 1 more readable. As I said, it is misleading and distracting. – Carson63000 Sep 19 '13 at 2:29

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