When comparing a string variable to a string literal with .equals(), is there a standard practice for the order of items? [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 13 years ago.

There are benefits to each and I understand the differences, but what is considered best / standard practice? And why?

For example :

"myString".equals(myStringVar)

• Avoids a potential NPE and does not require a null check. (Good thing?)
• Cleaner to read since a null check is not required.
• If null is not an expected value, your program could be breaking without being any the wiser.

However

myStringVar.equals("myString")

• Requires a null check if null is an expected value. (Good thing?)
• Can clutter up compound conditionals with null checks.
• Allows for NPE to let us know if something has broken.

Which variation is considered the standard to use for Java, and why?

• Matthew Flynn: Whether or not null is an expected value, should the "equals" operation be the place to determine that this is problem?
• BrandonV: I don't think it is. But that is my opinion. I'd like to hear others' rationale.
• GordonM: In languages that use = and/or == for assignments/comparisons it's normally best practice to put the thing that can't change on the left so that you can't do an accidental assignment when you meant to do a comparison. For languages that use methods on an object like .equals I don't think it matters.

Answer 1

I suspect that this originates from a safety precaution used when programming in older C (or C++). In C, you could accidentally assign a value when you mean to test equality:

if (x = 3)

This condition will always be true, since it's assignment x a value of 3, not testing that x is equal to 3. To avoid this subtle bugs, developers started reversing the condition:

if (3 = x)

This contains the same "bug", but will generate a compiler error, so it's safer.

More modern languages don't have this problem, and they can easily warn you when you try to do these sorts of things. As such, it's no pretty much pure preference, so pick one, and use it consistently.

• Andres F.: -1 This isn't the reason for the Java convention for equals. Unlike in C, the problem for Java is that the expression x.equals(y) will throw a NPE when x is null. If you have a String literal "something" and you want to consider the case null as "not equals", it makes sense to write "something".equals(y) if you don't know whether y can be null. This will never throw an NPE.

Answer 2

• Standard and good practice would vary with a culture of an organisation you are working for

• Our standard in .NET is myStringVar == "myString" simply because we have agreed on it, i.e. we believe it to be clean and concsice

Note: This does not apply to Java due to == comparing the references instead of the objects themselves. In Java you should be using myStringVar.equals("myString").

• Michael K: At least in Java, do not use == because it only compares object references. That said, +1 for the setiment - convention often defines the "right" way of doing things.
• CodeART: Thank you for pointing this out! I've updated the answer :)
• amara: @CodeWorks: I think you missed Michael's point. Also, it's Java not JAVA.
• CodeART: Question was: "but what is considered best / standard practice? Why?" My answer is that standard and best practice varies from one organisation to another. Do you disagree with that?
• amara: @CodeWorks: Nobody could disagree with that, CodeWorks. But everyone could agree that myStringVar == "myString" is a deeply bad idea on Java (unless you are absolutely certain myStringVar is interned).

Answer 3

I think you're right in that it depends on the nullness semantics of the variable. If you don't expect it to be null and don't have to check for and handle it then the first form is cleaner.

That said, rather than embed the string literal, a better option would probably be this:

private final String MY_STRING = "myString";
if(MY_STRING).equals(myStringVar);

Especially if there is potential for using the string in more place than one.

• amara: -1: not actually better; adds clutter with usually negligible value
• Benjamin Wootton: @sparkleshy - Disagree, you really dont want string literals sprinkled through your code logic. As mentioned in original answer, if the string literal is used in more place than one then I'd definetly say to refactor them out.
• amara: To say that, you have to thoroughly diss python, since in python, identifiers basically ARE string literals. And I think we all have to agree that python is a fine language.