Do you use StringUtils.EMPTY
instead of ""
?
I mean either as a开发者_运维问答 return value or if you set a the value of a String variable. I don't mean for comparison, because there we use StringUtils.isEmpty()
Of course not. Do you really think "" is not clear enough ?
Constants have essentially 3 use cases:
- Document the meaning of a value (with constant name + javadoc)
- Synchronize clients on a common value.
- Provide a shortcut to a special value to avoid some init costs
None apply here.
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'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.
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""
andStringUtils.EMPTY
the same object - Using
StringUtils.EMPTY
can initializeStringUtils
class, as it accesses its static memberEMPTY
only if it is not declaredfinal
(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 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).
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.
I find StringUtils.EMPTY
useful in some cases for legibility. Particularly with:
Ternary operator eg.
item.getId() != null ? item.getId() : StringUtils.EMPTY;
- 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?
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 " ";
Honestly, I don't see much use of either. If you want to compare egainst an empty string, just use StringUtils.isNotEmpty(..)
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.
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.
精彩评论