Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

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


  • 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.
share|improve this question

closed as not a real question by Jarrod Roberson, gnat, Walter, ChrisF May 7 '12 at 21:22

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.If this question can be reworded to fit the rules in the help center, please edit the question.

Whether or not null is an expected value, should the "equals" operation be the place to determine that this is problem? – Matthew Flynn May 7 '12 at 20:04
I don't think it is. But that is my opinion. I'd like to hear others' rationale. – BrandonV May 7 '12 at 20:15
  • Standard and good practice would vary with a culture of an organisation you are working for

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

Note: my statement applies to .NET and JAVA

share|improve this answer
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 '12 at 20:22
Thank you for pointing this out! I've updated the answer :) – CodeART May 7 '12 at 20:24
@CodeWorks: I think you missed Michael's point. Also, it's Java not JAVA. – naiad May 7 '12 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 '12 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). – naiad May 9 '12 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.

share|improve this answer
-1: not actually better; adds clutter with usually negligible value – naiad May 7 '12 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. – Benjamin Wootton May 9 '12 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. – naiad May 9 '12 at 13:19

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.

share|improve this answer

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