Você usa em StringUtils.EMPTY
vez de ""
?
Quero dizer, tanto como um valor de retorno ou se você definir o valor de uma variável String. Não é para comparação, porque lá usamosStringUtils.isEmpty()
Respostas:
Claro que não. Você realmente acha que "" não é claro o suficiente?
As constantes têm essencialmente 3 casos de uso:
Nenhum se aplica aqui.
EMPTY
não tem nenhum significado que a própria string vazia já não tenha. Mais notavelmente, ele não documenta por que você decidiu usar uma string vazia naquele caso específico. Não é diferente nomear uma constante ONE
e fingir que há um ponto em usar essa constante em vez do valor.
Eu uso StringUtils.EMPTY
, para ocultar o literal e também para expressar que return StringUtils.EMPTY
era totalmente esperado e que deveria retornar uma string vazia, ""
pode levar à suposição de que ""
pode ser facilmente transformado em outra coisa e que isso talvez tenha sido apenas um erro. Eu acho que o EMPTY
é mais expressivo.
StringUtils.EMPTY
menos expressivo do que ""
.
""
que é mais expressivo do que usar StringUtils.EMPTY
, e o que você disse não mudou minha opinião sobre isso. Posso quase acreditar que os desenvolvedores escreveram incorretamente um literal de string vazio muito, muito ocasionalmente - mas vou considerar a clareza do literal de string em relação ao que é uma vez em um milhão (e facilmente encontrado em testes, espero ... ) bug, pessoalmente.
Não, apenas use ""
.
O literal ""
é claro como cristal. Não há mal-entendido quanto ao que foi feito. Eu não sei por que você precisa de uma constante de classe para isso. Só posso assumir que essa constante é usada em todo o pacote que contém, em StringUtils
vez de ""
. Isso não significa que você deva usá-lo.
Se houver uma pedra na calçada, você não precisa jogá-la.
Estou surpreso com quantas pessoas ficam felizes em presumir cegamente que "" é de fato uma string vazia e não contém (acidentalmente?) Nenhum dos maravilhosos caracteres invisíveis e sem espaçamento do Unicode. Pelo amor de tudo o que é bom e decente, use EMPTY sempre que puder.
Vou adicionar meus dois centavos aqui porque não vejo ninguém falando sobre String
estagiário e inicialização de classe:
String
literais em fontes Java são internados, tornando todo ""
e StringUtils.EMPTY
o mesmo objetoStringUtils.EMPTY
pode inicializar a StringUtils
classe, pois acessa seu membro estático EMPTY
apenas se não estiver declaradofinal
(o JLS é específico nesse ponto). No entanto, é final, por isso não inicializará a classe.org.apache.commons.lang3.StringUtils.EMPTY
Veja uma resposta relacionada em String interning e em Class initialization , referindo-se ao JLS 12.4.1 .
StringUtils
classe.
Não gosto muito de usar, porque return "";
é mais curto que return StringUtils.EMPTY
.
No entanto, uma falsa vantagem de usá-lo é que se você digitar em return " ";
vez de return "";
, poderá encontrar um comportamento diferente (em relação ao teste correto de uma String vazia ou não).
""
, odeio digitar a mesma string literal mais de uma vez, mesmo que apenas uma vez às vezes. Prefiro declarar constantes em Constants.java , mas não repeti-las em todos os lugares no código-fonte.
return "";
é feio, PREFERO usar return StringUtil.EMPTY
(declarado em minha própria classe StringUtil , NÃO StringUtils do Apache ).
Se sua classe não usa mais nada dos comuns, seria uma pena ter essa dependência apenas para esse valor mágico.
O designer dos StringUtils faz uso intenso dessa constante, e é a coisa certa a se fazer, mas isso não significa que você deve usá-la também.
Honestamente, não vejo muita utilidade em nenhum dos dois. Se você quiser comparar eg contra uma string vazia, basta usarStringUtils.isNotEmpty(..)
StringUtils.isNotEmpty(..)
também faz uma verificação nula, então não é exatamente o mesmo que comparar com uma string vazia.
null
? como um segundo argumento de equals
, mas o resultado será o mesmo -false
isNotEmpty
é o oposto de "".equals(…)
, portanto, o fato de que ele tratará null
como uma string vazia é diferente de comparar com uma string vazia, "".equals("")
→ true
, "".equals(null)
→ false
, StringUtils.isNotEmpty("")
→ false
, StringUtils.isNotEmpty(null)
→ false
. Se você apenas quer saber se uma string está vazia, use string.isEmpty()
, que tem o comportamento correto de retornar true
iff for uma string vazia e lançar um NullPointerException
se a string for null
...
Acho StringUtils.EMPTY
útil em alguns casos para legibilidade. Particularmente com:
Operador ternário, por exemplo.
item.getId() != null ? item.getId() : StringUtils.EMPTY;
Também usando uma constante, uma referência a StringUtils.EMPTY
é criada. Caso contrário, se você tentar instanciar o literal String ""
cada vez, a JVM terá que verificar se ele já existe no pool de String (o que provavelmente acontecerá, portanto, nenhuma sobrecarga de criação de instância extra). Certamente o uso StringUtils.EMPTY
evita a necessidade de verificar o pool de String?
StringUtils.EMPTY
constante é resolvida em tempo de compilação.
StringUtil.EMPTY
é uma constante de tempo de compilação, uma referência a ela é compilada exatamente no mesmo bytecode usado ""
diretamente. Além disso, não vejo por que o operador ternário deveria fazer alguma diferença. É uma expressão como qualquer outra. Qualquer motivo para usar ou não uma constante nomeada também se aplica ao operador ternário.
Não, porque tenho mais a escrever. E um vazio String é plattform independente vazio (em Java).
File.separator
é melhor que "/" ou "\".
Mas faça o que quiser. Você não pode obter um erro de digitação comoreturn " ";
someString.isEmpty()
vez disso.
Sim, faz sentido. Pode não ser o único caminho a percorrer, mas vejo muito pouco na maneira de dizer que "não faz sentido".
Na minha opinião:
It will still require changing everywhere if you don't define your own variable and use it in multiple places.
você vai mudar uma string vazia para uma string vazia diferente?
StringUtils.EMPTY
. Deixa claro que o uso da String vazia é intencional, e não algum tipo de preguiça ("Ah, isso requer uma String, vamos passar""
"). Se alguém acessar esse código, ele pensará duas vezes antes de fazer alterações. Além disso, seStringUtils.EMPTY
fosse definida como sua própria variável, por exemploMyClass.EMPTY
, fazer alterações em "aquela representação do vazio" exigiria alterar uma linha de código. Você pode, por exemplo, alterá-lo para em"<empty>"
vez da String vazia""
. Mas, acho que isso está indo longe demais.