StringUtils.Empty 推荐吗?

你用 StringUtils.EMPTY代替 ""吗?

我的意思是作为一个返回值或者如果你设置一个字符串变量的值。我不是说比较,因为在那里我们使用 StringUtils.isEmpty()

107365 次浏览

I don't really like to use it, as return ""; is shorter than return StringUtils.EMPTY.

However, one false advantage of using it is that if you type return " "; instead of return "";, you may encounter different behavior (regarding if you test correctly an empty String or not).

No, because I have more to write. And an empty String is plattform independent empty (in Java).

File.separator is better than "/" or "\".

But do as you like. You can't get an typo like return " ";

If your class doesn't use anything else from commons then it'd be a pity to have this dependency just for this magic value.

The designer of the StringUtils makes heavy use of this constant, and it's the right thing to do, but that doesn't mean that you should use it as well.

Of course not. Do you really think "" is not clear enough ?

Constants have essentially 3 use cases:

  1. Document the meaning of a value (with constant name + javadoc)
  2. Synchronize clients on a common value.
  3. Provide a shortcut to a special value to avoid some init costs

None apply here.

Honestly, I don't see much use of either. If you want to compare egainst an empty string, just use StringUtils.isNotEmpty(..)

I use StringUtils.EMPTY, for hiding the literal and also to express that return StringUtils.EMPTY was fully expected and there should return an empty string, "" can lead to the assumption that "" can be easily changed into something else and that this was maybe only a mistake. I think the EMPTY is more expressive.

No, just use "".

The literal "" is clear as crystal. There is no misunderstanding as to what was meant. I wouldn't know why you would need a class constant for that. I can only assume that this constant is used throughout the package containing StringUtils instead of "". That doesn't mean you should use it, though.

If there's a rock on the sidewalk, you don't have to throw it.

I find StringUtils.EMPTY useful in some cases for legibility. Particularly with:

  1. Ternary operator eg.

    item.getId() != null ? item.getId() : StringUtils.EMPTY;
    
  2. Returning empty String from a method, to confirm that yes I really wanted to do that.

Also by using a constant, a reference to StringUtils.EMPTY is created. Otherwise if you try to instantiate the String literal "" each time the JVM will have to check if it exists in the String pool already (which it likely will, so no extra instance creation overhead). Surely using StringUtils.EMPTY avoids the need to check the String pool?

I will add my two cents here because I don't see anybody talking about String interning and Class initialization:

  • All String literals in Java sources are interned, making any "" and StringUtils.EMPTY the same object
  • Using StringUtils.EMPTY can initialize StringUtils class, as it accesses its static member EMPTY only if it is not declared final (the JLS is specific on that point). However, org.apache.commons.lang3.StringUtils.EMPTY is final, so it won't initialize the class.

See a related answer on String interning and on Class initialization, referring to the JLS 12.4.1.

I'm amazed at how many people are happy to blindly assume that "" is indeed an empty string, and doesn't (accidentally?) contain any of Unicode's wonderful invisible and non-spacing characters. For the love of all that is good and decent, use EMPTY whenever you can.

Yes, it makes sense. It might not be the only way to go but I can see very little in the way of saying this "doesn't make sense".

In my opinion:

  • It stands out more than "".
  • It explains that you meant empty, and that blank will likely not do.
  • It will still require changing everywhere if you don't define your own variable and use it in multiple places.
  • If you don't allow free string literals in code then this helps.

I am recommending to use this constant as one of the building stones of a robust code, to lower the risk of accidently have nonvisible characters sneak in when assigning an empty string to a variable.

If you have people from all around the world in your team and maybe some of them not so experienced, then it might be a good idea to insist on using this constant in the code.

There are lots of different languages around and people are using their own local alphabet settings on their computers. Sometimes they just forget to switch back when coding and after they switch and delete with backspace, then text editor can leave some junk inside of "". Using StringUtils.EMPTY just eliminate that risk.

However, this does not have any significant impact on the performance of the code, nor on the code readability. Also it does not resolve some fundamental problem you might experience, so it is totally up to your good judgement weather you will use this constant or not.