i=i+1 vs i+=1(short i)

[Catherine Fang]

Hi

What are the difference between the expression (short i; i=i+1) and (short i;i+=1)?
Although I can't see the meaning of the question, I just a little interested in it.

Thanks

[Gautam Joshi]

Hi Catherine..,

There is no difference in these, except the way of expression you choose.

both will do the same thing.. but one is Handy( i += 1;) and the other is not(Not in this case, but when there is a long name of a member).

[Mike Simmons]

Well, neither of these will compile, since i has not been initialized. But assuming that we fix that by replacing "short i;" with "short i = 0;"...

The statements

short i = 0;
i += 1;

are actually equivalent to

short i = 0;
i = (short) (i + 1);

The code won't compile without that cast to short. This issue doesn't usually show up for people, because most people use int, long, or double - most of the time. Interesting that you happened to use short here.

So the += notation is just a more compact way of writing that.

[Jesper de Jong]

Another way to increment the variable i is to use the ++ operator:

short i = 0;
i++;
// This will print 1
System.out.println(i);

[Campbell Ritchie]

Why are you using a short in the first place?

[Dieter Quickfend]

I would recommend to always use the "i=i+1" notation for clarity.

[Winston Gutkowski]

 

Dieter Quickfend wrote:I would recommend to always use the "i=i+1" notation for clarity.

Hmmm. Even when a cast is required? Not sure I agree, but I understand your reasoning.

I reckon Jesper's suggestion is even better.

Winston

[Campbell Ritchie]

There is nothing unclear about i++;
There is however no end of scope for confusion when you use i++ as part of another statement. You need to be very careful whenever you do that.

[Dieter Quickfend]

 

Campbell Ritchie wrote:There is nothing unclear about i++;
There is however no end of scope for confusion when you use i++ as part of another statement. You need to be very careful whenever you do that.

I can definitely understand that idea. On its own this statement is clear enough. However, think about how many times it's used as the sole content of that statement.

I was a java instructor before I started consultancy, and perhaps even more important than code clarity, is clarity about code clarity.

Always is better than sometimes. You cannot say to a beginner "this is sometimes the better choice" and then be surprised he tried "i-1+=5++".

When I was learning java, there was a guy in my classroom who was already an adept C programmer. For a certain exercise, I wrote an application of a few dozen lines of code. His application was a main method with an if statement that did nothing but print out "program finished". All the logic was in the if statement. Not in the block, but in the statement itself.

It takes a good java programmer to understand fully how things like "i++" or "++i" work. Anyone with basic math skills will understand "i=i+1".

[Jayesh A Lalwani]

I'm sorry but if you are having trouble understanding this code

for(i=0; i<10; i++) {
System.out.println(beerSong[i]);
}

You are not getting hired as a Java developer. No matter what your instructor says.

[Winston Gutkowski]

 

Dieter Quickfend wrote:Anyone with basic math skills will understand "i=i+1".

Yes, but my point (actually Mike's) is that in the case specified in the OP, that won't work.

It must be specifically:
i = (short) (i + 1);
whereas
i += 1;
will work regardless of i's type.

Winston

[Mike Simmons]

 

Dieter Quickfend wrote:Anyone with basic math skills will understand "i=i+1".

Mmm, from a basic math perspective, that simply looks like a false statement. It implies 0 = 1, and no value of i can make that true.

More to the point though, I can accept "use i = i + 1" as initial advice for beginners, OK -- but if they finish the course thinking it's always preferable, or if they finish and still think i++ or i += 1 are in any way hard to read... well, they've got a lot more studying ahead before they'll be able to work productively.

Now personally, I will happily use +=, -=, *=, /=, &=, or |= on the rare cases that they make sense. I will concede that all but the first of those are a bit unusual to see in code, and that may be a valid reason to avoid them. But for professional work, anyone who can't at least read +=, easily, really needs to be dropped from the team.

[Campbell Ritchie]

You need to be careful with += and similar; they cause a widening and narrowing primitive conversion and can cause strange results with operands of mixed types.

short s = 123;
s += 0.123f;
System.out.println(s)

Can you predict what will happen: will that code compile, will it throw an Exception if you run it, what will it print?

int i = 123;
i += 543;
System.out.println(i);

Can you predict what will happen: will that code compile, will it throw an Exception if you run it, what will it print?
There is a section in Java Puzzlers by Bloch and Gafter about that sort of code.

[Rico Felix]

All one has to understand about the += operator is that in an expression it expands to: x = (cast to type of x) (x + (expression));

Whereas in an expression which is expressed as x = x + some type... type promotion has to be taken into consideration which can affect the assignment operation

[Campbell Ritchie]

In which case, will the following code compile (if inside a correctly‑written method)? Will it run without exceptions? What will it print?

short s = 23456;
s += 65432;
System.out.println(s);

[Dieter Quickfend]

 

Mike Simmons wrote:

Dieter Quickfend wrote:Anyone with basic math skills will understand "i=i+1".

Mmm, from a basic math perspective, that simply looks like a false statement. It implies 0 = 1, and no value of i can make that true.

More to the point though, I can accept "use i = i + 1" as initial advice for beginners, OK -- but if they finish the course thinking it's always preferable, or if they finish and still think i++ or i += 1 are in any way hard to read... well, they've got a lot more studying ahead before they'll be able to work productively.

Now personally, I will happily use +=, -=, *=, /=, &=, or |= on the rare cases that they make sense. I will concede that all but the first of those are a bit unusual to see in code, and that may be a valid reason to avoid them. But for professional work, anyone who can't at least read +=, easily, really needs to be dropped from the team.

I think I've been misinterpreted. My comment was not exactly aimed at this specific statement or its validity; I simply mean that clarity is always preferable over brevity, whether that's in terms of operators or anything else. Most of the code you need to understand to start a job, like most of the code you need to be able to analyze for OCPJP exam etcetera, is code that is so badly written it would be simply disastrous in a large application. There is no excuse for using "i++" anywhere in an enterprise application (except the occasional for loop). Also I thought about mentioning that even "i=i+1" would need basic understanding of the assignment operator in java, but I didn't mention it because it would complicate the point I was trying to make.

While you need to be able to understand complex code to qualify for a job as a java developer, and you need to understand the ins and outs of all operators, it doesn't mean you should also use it on a daily basis. There are many things I will avoid in an enterprise application, including the increment operator (except for the classic 'for' loop) and heavy use of the switch operator. Anyone would feel inclined to drop a developer who doesn't understand "+=", in fact I'm sure he wouldn't even have been hired, but I will honestly feel just as horrified if a developer chooses to write "i+=5++;" in an application, no matter its validity.

[Winston Gutkowski]

 

Dieter Quickfend wrote:I simply mean that clarity is always preferable over brevity...

Now there, I can't disagree. And that extends to things like good naming, proper indentation and spacing, and following coding conventions.

There is no excuse for using "i++" anywhere in an enterprise application (except the occasional for loop).

And I'd agree with you there too. But (as I'm sure you know), i++ is not the same thing as ++i; and, to be honest, I've never understood why the first one seems to have gained preference. And the fact is that i=i+1 is equivalent to the latter, not the first.

There are many things I will avoid in an enterprise application, including the increment operator (except for the classic 'for' loop) and heavy use of the switch operator...

And there's where we part company:

Campbell's post referred to using increments in combination with other things. On their own, they're the simplest, clearest (and probably fastest) way of doing what you want. Furthermore, providing you use ++i, you can even put them once in an expression without too much fear of tying yourself in mental knots; although I'd agree that separating them out is better.

And as for switches, I couldn't disagree more. To me, they are way clearer than if...else stacks, so I will use them any place I possibly can. The only caveat I would make is that using either switch OR if...else a lot tends to smell of dispatch code which, in an object-oriented language, can often be handled far more clearly with polymorphism.


Going back to increments, I think that "combining" them goes back to the days of C, when it often made the resulting machine code more compact and faster, resulting in monstrosities like:

// returns 0 (false) if str is not a palindrome; otherwise 1.
int isPalindrome(char *str) {
int length = strlen(str);
if (!length) // another classic C horror... :-)
return 0;
char *end = str + length;
while(str < end) {
if (*(str++) != *(--end))
return 0;
}
return 1;
}

(there might be some mistakes, it's ages since I did C; but that one sticks in my mind )

My 2¢.

Winston

[Campbell Ritchie]

You could buy books telling you how wonderful that sort of C code is!

[Dieter Quickfend]

You make good points. I avoid if...else stacks just as much as I avoid switches. I am also fully aware of the evaluation differences between "i++" and "++i". What I'm saying is that if you find yourself in a position where that difference determines whether your application is functional... you've already lost the technical debt match. There is nothing easier to miss than that. You will read it twenty times, and even knowing the difference, you won't notice it.

Very interesting discussion though. It seems that no one agrees with me on the increment operator, which I find surprising.

[Winston Gutkowski]

 

Dieter Quickfend wrote:What I'm saying is that if you find yourself in a position where that difference determines whether your application is functional... you've already lost the technical debt match. There is nothing easier to miss than that. You will read it twenty times, and even knowing the difference, you won't notice it.

Hmmm, so you're saying that Java shouldn't have allowed i++? It's certainly the one I'd get rid of, but I suspect it might surprise a lot of people who expect "C-style" syntax from Java.

It also doesn't solve your problem. The fact is that i = i+1 can ALSO be put in expressions, since an assignment has a value. Indeed, I use things like:
while((line = bufferedStream.readLine()) != null) { ...
a lot.

Very interesting discussion though. It seems that no one agrees with me on the increment operator, which I find surprising.

I think it's more that we think you might be being a bit AR about it. Languages are meant to be used; but in order to use them, you have to learn them. I think your 'rule' is fine for real newbies, but at the end of the day, they've got to find their own way; so I tend to point them to articles like this and this when I think they're ready.

Winston