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

For example :

  • 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.


  • 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?

  • 2
    Whether or not null is an expected value, should the "equals" operation be the place to determine that this is problem? May 7, 2012 at 20:04
  • I don't think it is. But that is my opinion. I'd like to hear others' rationale.
    – BrandonV
    May 7, 2012 at 20:15
  • 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.
    – GordonM
    Mar 18, 2016 at 14:30

3 Answers 3


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.

  • -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.
    – Andres F.
    Mar 15, 2016 at 18:35
  • 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").

  • 3
    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.
    – Michael K
    May 7, 2012 at 20:22
  • Thank you for pointing this out! I've updated the answer :)
    – CodeART
    May 7, 2012 at 20:24
  • @CodeWorks: I think you missed Michael's point. Also, it's Java not JAVA.
    – amara
    May 7, 2012 at 21:41
  • 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?
    – CodeART
    May 7, 2012 at 21:49
  • @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).
    – amara
    May 9, 2012 at 13:22

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";

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

  • 2
    -1: not actually better; adds clutter with usually negligible value
    – amara
    May 7, 2012 at 21:42
  • @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. May 9, 2012 at 13:17
  • 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.
    – amara
    May 9, 2012 at 13:19

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