Tim Driven Development | Test until the fear goes away
Just go through this diagram I created to understand String pool concept.When I asked why he mentioned something about literal strings being interned in Java which tbh went over my head.
Being Java programmer.
Tim Cooke wrote:We have a Wiki page all about that: Avoid The Equality Operator
Ganish Patil wrote:
Just go through this diagram I created to understand String pool concept.When I asked why he mentioned something about literal strings being interned in Java which tbh went over my head.
Only you have to keep in mind, when at step 4(To see step numbers, look at digits in red circle at left side) strThree.intern() If "Java" literal's reference wasn't in pool then same object i.e. having reference location 2007 would have returned.
You have been lucky. If is only a matter of time before you write = and get two errors for the price of one. == true and == false are also poor style.Fergus Flanagan wrote:. . . I've used '==' on booleans and it's worked fine so far
Yes. The only place you really need to know whether you have the same object twice is probably the equals() method. The equals() method is not really a beginner's topic because of its difficulty.. . . When you need to see whether you have two references to the same object use '=='
And for an objects component use .equals
Campbell Ritchie wrote:It is only a matter of time before you write = and get two errors for the price of one.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Campbell Ritchie wrote:It is only a matter of time before you write = and get two errors for the price of one.
Or, even worse, DON'T get an error, but create an unintended bug.
Winston
if (b==true) is more self-documenting code than if (b).
All things are lawful, but not all things are profitable.
Disagree. Once one has understood the concept of a predicate, the == true becomes obviously redundant.Mike London wrote:. . . if (b==true) is more self-documenting code than if (b). . . .
I obviously wasn't clear; I meant a logic error causing incorrect results, which does not so much translate to a bug, but two bugs for the price of one.Winston Gutkowski wrote:. . . Or, even worse, DON'T get an error, but create an unintended bug. . . .
Campbell Ritchie wrote:
I obviously wasn't clear; I meant a logic error causing incorrect results, which does not so much translate to a bug, but two bugs for the price of one.Winston Gutkowski wrote:. . . Or, even worse, DON'T get an error, but create an unintended bug. . . .
Mike London wrote:but on the other hand, if (b==true) is more self-documenting code than if (b).
Tim Driven Development | Test until the fear goes away
I usually simply write b as a generic name for any boolean. Knuet's example with a good variable name makes that point clear.Tim Cooke wrote:. . . the boolean variable is poorly named. . . .
Careful about spellings; you probably mean booleans not Boolean.Mike London wrote:. . . "==" for comparing Booleans and agree with you. . . .
Campbell Ritchie wrote:I have enhanced your code to show that you can get any number of logic errors following that mistaken assignment.
Careful about spellings; you probably mean booleans not Boolean.Mike London wrote:. . . "==" for comparing Booleans and agree with you. . . .
All things are lawful, but not all things are profitable.
Knute Snortum wrote:And if you happen to be using Eclipse, you can do this without a plugin:
Windows > Preferences > Java > Compiler > Errors/Warnings. Look under Potential programming problems.
I have linked to that post elsewhere so for that post.Mike London wrote:. . . Of course, code like this makes me rethink my position: . . .
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |