¿Se recomienda StringUtils.EMPTY?

91

¿Usas en StringUtils.EMPTYlugar de ""?

Me refiero a como valor de retorno o si establece el valor de una variable de cadena. No me refiero a la comparación, porque allí usamosStringUtils.isEmpty()

java string apache-commons

— keuleJ
fuente

111

Por supuesto no. ¿De verdad crees que "" no es lo suficientemente claro?

Las constantes tienen esencialmente 3 casos de uso:

Documentar el significado de un valor (con nombre constante + javadoc)
Sincronice a los clientes en un valor común.
Proporcione un atajo a un valor especial para evitar algunos costos de inicio

Ninguno se aplica aquí.

— David Pierre
fuente

33

Todavía veo un caso de uso menor y raro para StringUtils.EMPTY. Deja en claro que el uso de String vacío es intencionado, y no una especie de pereza ("Oh, esto requiere un String, pasemos """). Si alguien pulsa este código, lo pensará dos veces antes de realizar cambios. Además, si StringUtils.EMPTYse definiera como su propia variable, como MyClass.EMPTY, hacer cambios en "esa representación del vacío" requeriría cambiar una línea de código. Por ejemplo, podría cambiarlo a en "<empty>"lugar del String vacío "". Pero, creo que esto va demasiado lejos.

— Timmos

5

Finalmente, tengo un argumento sensato al que reenviar a los fanáticos, en lugar de pensar por mi cuenta cada vez. Gracias.

— Alex

2

¿Cómo carece de significado VACÍO? EMPTY satisface tanto el 1 como el 2 en su lista. Los desarrolladores experimentados están subestimando severamente el potencial de los desarrolladores junior de estropear algo tan simple como usar "".

— Andrew T Finnell

4

@AndrewTFinnell el nombre EMPTYno tiene ningún significado que la cadena vacía en sí misma no tenga. En particular, no documenta por qué decidió usar una cadena vacía en ese caso en particular. No es diferente a nombrar una constante ONEy pretender que tenía un sentido usar esa constante en lugar del valor.

— Holger

6

Votos en contra solo porque, no, en realidad no creo que "" sea lo suficientemente claro :( ¿Está en blanco? ¿Está vacío? ¿Hay un espacio allí que no puedo ver porque mi tamaño de fuente es pequeño? ¿Estar vacío? ¿Hay caracteres extraños "invisibles"?

— Dan Rayson

60

Utilizo StringUtils.EMPTY, para ocultar el literal y también para expresar que return StringUtils.EMPTYse esperaba completamente y que debería devolver una cadena vacía, ""puede llevar a la suposición de que ""se puede cambiar fácilmente a otra cosa y que esto tal vez fue solo un error. Creo que EMPTYes más expresivo.

— Christopher Klewes
fuente

37

Según otros que han sugerido esto: ¿también usa CERO para 0 y UNO para 1?

— Jon Skeet

9

No compararía el caso especial "vacío" con el uso del literal entero.

— Christopher Klewes

16

Me parece StringUtils.EMPTY menos expresivo que "".

— bacar

1

@JonSkeet Mucho respeto por ti. Siento que estás equivocado aquí. Si bien es posible que usted y yo nunca nos encontremos con esto, hay un caso para no usar el literal "", ya que no proporciona una verificación de sintaxis si un desarrollador lo estropea. Y sí, he visto a desarrolladores junior estropear cosas simples como "". No creo en la idea de cambiar VACÍO para que signifique algo más que "". Me gusta la idea de EMPTY solo por el hecho de que el compilador es capaz de entender su significado.

— Andrew T Finnell

@AndrewTFinnell: "Incorrecto" es un término extraño para lo que seguramente debe ser subjetivo. No, no espero que VACÍO nunca cambie de significado, pero yo, como bacar, encuentro ""ser más expresivo que el uso StringUtils.EMPTY, y lo que has dicho no ha cambiado de opinión al respecto. Casi puedo creer que los desarrolladores han escrito incorrectamente un literal de cadena vacía muy, muy ocasionalmente , pero tomaré la claridad del literal de cadena sobre el de una vez en un millón (y se encontrará fácilmente en las pruebas, con suerte ... ) error, personalmente.

— Jon Skeet

29

No, solo usa "".

Lo literal ""es claro como el cristal. No hay ningún malentendido en cuanto a lo que se quiso decir. No sabría por qué necesitarías una constante de clase para eso. Solo puedo asumir que esta constante se usa en todo el paquete que contiene en StringUtilslugar de "". Sin embargo, eso no significa que debas usarlo.

Si hay una piedra en la acera, no es necesario que la arrojes.

— Erick Robertson
fuente

6

"Si hay una piedra en la acera, no tienes que tirarla". Dile eso a mi hijo de 6 años.

— roel

14

Estoy asombrado de cuántas personas están felices de asumir ciegamente que "" es de hecho una cadena vacía y no contiene (¿accidentalmente?) Ninguno de los maravillosos caracteres invisibles y sin espacios de Unicode. Por amor a todo lo que es bueno y decente, use EMPTY siempre que pueda.

— j__m
fuente

4

Tengo curiosidad, ¿alguna vez has visto que esto suceda en código? Si es así, ¿fue accidental o intencionalmente? Parecería difícil hacerlo accidentalmente, y si fuera a propósito, podría crear fácilmente mi propia clase StringUtils con una constante EMPTY no vacía, y referirme a eso.

— Ian Robertson

5

@IanRobertson Sí, he visto que esto suceda. En realidad, muy a menudo. Las personas cortan y pegan desde sitios web todo el tiempo y desde un conjunto de códigos a otro conjunto de códigos. También hay empresas que todavía usan Clear Case, que usa un conjunto de códigos arcaico, que luego se traduce ciegamente al conjunto ISO de Windows, y luego se traduce a UTF-8 si se cambia a Git. He pasado incontables horas solucionando problemas de conjuntos de códigos. Incluyendo éste.

— Andrew T Finnell

3

@AndrewTFinnell Ciertamente puedo ver cómo, en general, eso podría causar problemas. Pero, ¿con qué frecuencia ha visto específicamente una constante String de aspecto vacío no vacía?

— Ian Robertson

13

Agregaré mis dos centavos aquí porque no veo a nadie hablando sobre Stringpasantías e inicialización de clases:

Todos los Stringliterales en las fuentes de Java son internados, por lo que cualquier "" y StringUtils.EMPTYel mismo objeto
El uso StringUtils.EMPTY puede inicializar la StringUtilsclase, ya que accede a su miembro estático EMPTY solo si no está declaradofinal (el JLS es específico en ese punto). Sin embargo, es final, por lo que no inicializará la clase.org.apache.commons.lang3.StringUtils.EMPTY

Consulte una respuesta relacionada sobre la internación de cadenas y la inicialización de clases , refiriéndose a JLS 12.4.1 .

— Matthieu
fuente

“Solo si no se declara final”, por lo que como este campo se declara final, acceder a él no puede provocar la inicialización de la StringUtilsclase.

— Holger

@Holger esa fue una declaración general, pero de hecho, edité con un enlace al javadoc que muestra que es final (y por lo tanto no inicializará la clase).

— Matthieu

8

Realmente no me gusta usarlo, ya que return "";es más corto que return StringUtils.EMPTY.

Sin embargo, una falsa ventaja de usarlo es que si escribe en return " ";lugar de return "";, puede encontrar un comportamiento diferente (con respecto a si prueba correctamente una Cadena vacía o no).

— Romain Linsolas
fuente

13

¿Alguna vez ha observado que esto es realmente un problema (usando "" accidentalmente donde quiso decir "")? Personalmente, encuentro el literal más legible y nunca me ha causado ningún problema.

— Jon Skeet

2

@Jon No, de hecho, pero traté de encontrar una ventaja al usarlo;)

— Romain Linsolas

1

No existe una regla de tiempo igual. Si no hay ventaja, entonces no hay ventaja.

— Erick Robertson

1

Tampoco me gusta "", odio escribir la misma cadena literal más de una vez, incluso una sola vez. Prefiero declarar constantes en Constants.java , pero no repetirlas en todas partes en el código fuente.

— 賈可 Jacky

2

Yo CREO return ""; es feo, PREFIERO utilizar retorno StringUtil.EMPTY(declarado en mi propia clase StringUtil , de NO Apache StringUtils ).

— 賈可 Jacky

5

Si su clase no usa nada más de los comunes, sería una pena tener esta dependencia solo por este valor mágico.

El diseñador de StringUtils hace un uso intensivo de esta constante, y es lo correcto, pero eso no significa que tú también debas usarla.

— Cherouvim
fuente

Quise decir que es aceptable ya que el autor eligió ir de esta manera (evite cualquier uso de "valores mágicos"). Sin embargo, debería ser privado.

— Cherouvim

El autor usa 0 frecuentemente en el código. ¿Hubiera sido mejor para ellos definir también una constante int ZERO = 0? Si no es así, ¿cuál es la diferencia?

— Jon Skeet

6

Depende del contexto. Si se tratara de un FCKEditorStringUtils, su VACÍO sería "<p> & nbsp </p>" y preferiría que se reutilizara VACÍO en lugar de replicar este valor mágico en todas partes de la clase. Entonces, por EMPTY probablemente se refieran a EMPTY_CONTENT y no a EMPTY_STRING (por lo que su ejemplo CERO es un poco injusto). ¿No reutilizaría una constante ERROR_VISA_INVALID = 0?

— Cherouvim

1

Honestamente, no veo mucho uso de ninguno de los dos. Si desea comparar econtra una cadena vacía, simplemente useStringUtils.isNotEmpty(..)

— Bozho
fuente

2

StringUtils.isNotEmpty(..)también realiza una verificación nula, por lo que no es exactamente lo mismo que comparar con una cadena vacía.

— Cherouvim

y cómo va a campare null? como segundo argumento de equals, pero el resultado será el mismo -false

— Bozho

isNotEmptyes lo contrario de "".equals(…), por lo tanto, el hecho de que tratará nullcomo la cadena vacía es diferente a comparar con una cadena vacía, "".equals("")→ true, "".equals(null)→ false, StringUtils.isNotEmpty("")→ false, StringUtils.isNotEmpty(null)→ false. Si solo desea saber si una cadena está vacía, use string.isEmpty(), que tiene el comportamiento correcto de devolver truesi es una cadena vacía y lanzar un NullPointerExceptionsi la cadena es null…

— Holger

1

Encuentro StringUtils.EMPTYútil en algunos casos por legibilidad. Particularmente con:

Operador ternario, por ejemplo.

item.getId() != null ? item.getId() : StringUtils.EMPTY;

Devolviendo una cadena vacía de un método, para confirmar que sí, realmente quería hacer eso.

También al usar una constante, StringUtils.EMPTYse crea una referencia a . De lo contrario, si intenta crear una instancia del literal de cadena ""cada vez, la JVM tendrá que verificar si ya existe en el grupo de cadenas (lo que probablemente ocurrirá, por lo que no habrá gastos adicionales de creación de instancias). ¿Seguramente el uso StringUtils.EMPTYevita la necesidad de verificar el grupo de cadenas?

— Tom
fuente

4

Su argumento con las múltiples búsquedas no se sostiene. En el capítulo 13.4.9 de Java Language Specification 3.0, se menciona que la StringUtils.EMPTYconstante se resuelve en tiempo de compilación.

— Roland Illig

4

La existencia en el grupo de cadenas se verifica en el tiempo de compilación y en el tiempo de carga de la clase, no en el tiempo de ejecución cada vez que ejecuta tal declaración,

— Marqués de Lorne

1

Dado que StringUtil.EMPTYes una constante en tiempo de compilación, una referencia a ella se compila exactamente en el mismo código de bytes que se usa ""directamente. Además, no veo por qué el operador ternario debería hacer alguna diferencia. Es una expresión como cualquier otra. Cualquier motivo para usar o no una constante con nombre también se aplica al operador ternario.

— Holger

1

No, porque tengo más que escribir. Y una cadena vacía es independiente de la plataforma vacía (en Java).

File.separator es mejor que "/" o "\".

Pero haz lo que quieras. No puedes obtener un error tipográfico comoreturn " ";

— Christian Kuetbach
fuente

7

No entiendo por qué la mayoría de los programadores tienen tanto miedo de escribir "demasiado". Al escribir StringUtils.EMPTY, logrará un código de autocomentario, uno que es más fácil de leer. Y según Steve McConnell (o algún estudio que citó en Code Complete 2.0) el código se lee 7 veces más de lo que está escrito.

— Paweł Dyda

1

Tiene mucha razón, PERO: "" .equals (someString) es tan fácil de leer como StringUtils.EMPTY.equals (someString)

— Christian Kuetbach

StringUtils.EMPTY.equals (someString) dará como resultado un error de sintaxis si lo escribe incorrectamente. "" .equals (someString) no lo hará. Ésta es la única razón por la que uno necesita usar EMPTY.

— Andrew T Finnell

1

@AndrewTFinnell es por eso que los programadores cuerdos escriben en su someString.isEmpty()lugar.

— Holger

-2

Sí, tiene sentido. Puede que no sea el único camino a seguir, pero puedo ver muy poco en la forma de decir que esto "no tiene sentido".

En mi opinión:

Destaca más que "".
Explica que quiso decir vacío, y ese espacio en blanco probablemente no servirá.
Aún será necesario cambiarlo en todas partes si no define su propia variable y la usa en varios lugares.
Si no permite literales de cadena libres en el código, esto ayuda.

— Oron
fuente

It will still require changing everywhere if you don't define your own variable and use it in multiple places.¿Vas a cambiar una cadena vacía por una cadena vacía diferente?

— Pita

@Pita Lo siento, esa fue una mala redacción. Quería decir que si usa este en línea en lugar de "" todavía no obtendrá los mismos beneficios que definir su propia constante y reutilizar en varios lugares. No es un argumento para StringUtils.EMPTY, es una explicación de que no obtienes mucho, incluso si 'tiene sentido'. Personalmente, crearía una constante con un nombre descriptivo y luego asignaría esto. He visto algunos casos en los que un desarrollador pretendía un solo espacio y terminó con una cadena vacía, lo que no sucede con este formulario.

— Oron