StringUtils.EMPTY est-il recommandé?

91

Utilisez-vous à la StringUtils.EMPTYplace de ""?

Je veux dire soit comme valeur de retour, soit si vous définissez la valeur d'une variable String. Je ne veux pas faire de comparaison, car là on utiliseStringUtils.isEmpty()

java string apache-commons keuleJ
la source

Réponses:

107

Bien sûr que non. Pensez-vous vraiment que "" n'est pas assez clair?

Les constantes ont essentiellement 3 cas d'utilisation:

  1. Documenter la signification d'une valeur (avec nom de constante + javadoc)
  2. Synchronisez les clients sur une valeur commune.
  3. Fournir un raccourci vers une valeur spéciale pour éviter certains coûts d'initialisation

Aucun ne s'applique ici.

David Pierre
la source
33
Je vois encore un cas d'utilisation mineur et rare pour StringUtils.EMPTY. Cela montre clairement que l'utilisation de la chaîne vide est prévue, et non une sorte de paresse ("Oh, cela nécessite une chaîne, passons """). Si quelqu'un frappe ce morceau de code, il réfléchira à deux fois avant d'apporter des modifications. De plus, si StringUtils.EMPTYétait défini comme votre propre variable, comme MyClass.EMPTY, apporter des modifications à «cette représentation de la vacuité» nécessiterait de changer une ligne de code. Vous pouvez, par exemple, le remplacer par une "<empty>"chaîne vide "". Mais je pense que cela va un peu trop loin.
Timmos
5
Enfin, j'ai un argument sensé vers lequel transmettre les fanatiques, au lieu de penser par moi-même à chaque fois. Merci.
Alex
2
Comment EMPTY manque-t-il de sens? EMPTY satisfait à la fois 1 et 2 dans votre liste. Les développeurs expérimentés sous-estiment gravement le potentiel des développeurs juniors à gâcher quelque chose d'aussi simple que d'utiliser "".
Andrew T Finnell
4
@AndrewTFinnell le nom EMPTYn'a aucune signification que la chaîne vide elle-même n'a pas déjà. Plus particulièrement, il ne documente pas pourquoi vous avez décidé d'utiliser une chaîne vide dans ce cas particulier. Ce n'est pas différent de nommer une constante ONEet de prétendre qu'il était utile d'utiliser cette constante au lieu de la valeur.
Holger le
6
Votes à la baisse simplement parce que, non, je ne pense pas que "" soit assez clair :( Est-ce vide? Est-il vide? Y a-t-il un espace que je ne vois pas parce que ma police est petite? être vide? Y a-t-il des caractères étranges "invisibles"?
Dan Rayson
59

J'utilise StringUtils.EMPTY, pour cacher le littéral et aussi pour exprimer ce qui return StringUtils.EMPTYétait pleinement attendu et qu'il devrait renvoyer une chaîne vide, ""peut conduire à l'hypothèse qui ""peut être facilement changée en autre chose et que ce n'était peut-être qu'une erreur. Je pense que EMPTYc'est plus expressif.

Christopher Klewes
la source
37
Comme par d'autres qui ont suggéré ceci: utilisez-vous également ZERO pour 0 et ONE pour 1?
Jon Skeet
9
Je ne comparerais pas le cas spécial «vide» à l'utilisation du littéral entier.
Christopher Klewes
16
Je trouve StringUtils.EMPTY moins expressif que "".
bacar le
1
@JonSkeet Beaucoup de respect pour vous. J'ai l'impression que vous vous trompez ici. Bien que vous et moi ne rencontrions jamais cela, il y a un cas à faire pour ne pas utiliser le littéral "" car il ne fournit aucune vérification de syntaxe si un développeur le gâche. Et oui, j'ai vu des développeurs juniors gâcher des choses simples comme "". Je n'accepte pas l'idée de changer constamment EMPTY pour signifier autre chose que "". J'aime l'idée de EMPTY uniquement pour le fait que le compilateur est capable de comprendre sa signification.
Andrew T Finnell
@AndrewTFinnell: "Incorrect" est un terme étrange pour ce qui doit sûrement être subjectif. Non, je ne m'attends pas à ce que EMPTY change un jour de sens, mais j'aime - comme le bacar - trouve que ""c'est plus expressif que d'utiliser StringUtils.EMPTY, et ce que vous avez dit n'a pas changé d'avis à ce sujet. Je peux à peu près croire que les développeurs ont mal écrit une chaîne vide littéralement très, très occasionnellement - mais je prendrai la clarté de la chaîne littérale sur une fois dans un million (et facilement trouvée dans les tests, espérons-le ... ) bug, personnellement.
Jon Skeet
29

Non, utilisez simplement "".

Le littéral ""est clair comme du cristal. Il n'y a pas de malentendu sur ce que cela voulait dire. Je ne saurais pas pourquoi vous auriez besoin d'une constante de classe pour cela. Je ne peux que supposer que cette constante est utilisée dans tout le package contenant StringUtilsau lieu de "". Cela ne signifie pas pour autant que vous devriez l'utiliser.

S'il y a un rocher sur le trottoir, vous n'êtes pas obligé de le lancer.

Erick Robertson
la source
6
"S'il y a un rocher sur le trottoir, vous n'êtes pas obligé de le lancer." Dites ça à mon fils de 6 ans.
roel le
14

Je suis étonné de voir combien de personnes sont heureuses de supposer aveuglément que "" est en effet une chaîne vide et ne contient (accidentellement?) Aucun des merveilleux caractères invisibles et non espacés d'Unicode. Pour l'amour de tout ce qui est bon et décent, utilisez VIDE chaque fois que vous le pouvez.

j__m
la source
4
Je suis curieux - avez-vous déjà vu cela se produire dans le code? Si oui, était-ce accidentel ou exprès? Cela semblerait difficile à faire accidentellement, et si exprès, je pourrais tout aussi facilement créer ma propre classe StringUtils avec une constante EMPTY non vide, et y faire référence.
Ian Robertson le
5
@IanRobertson Oui, j'ai vu cela arriver. Assez souvent en fait. Les gens coupent et collent constamment des sites Web et d'un jeu de codes à un autre jeu de codes. Il existe également des entreprises qui utilisent encore Clear Case qui utilise un ensemble de codes archaïques, qui est ensuite traduit aveuglément dans l'ensemble ISO de Windows, puis traduit en UTF-8 si vous passez à Git. J'ai passé d'innombrables heures à résoudre les problèmes de jeux de codes. Y compris celui-ci.
Andrew T Finnell
3
@AndrewTFinnell Je peux certainement voir comment, en général, cela pourrait causer des problèmes. Mais à quelle fréquence avez-vous spécifiquement vu une constante String d'aspect vide non vide?
Ian Robertson
13

J'ajouterai mes deux cents ici car je ne vois personne parler de Stringstage et d'initialisation de classe:

  • Toutes les Stringlittéraux dans les sources Java sont internées, ce qui rend tout "" et StringUtils.EMPTYle même objet
  • L'utilisation StringUtils.EMPTY peut initialiser la StringUtilsclasse, car elle n'accède à son membre statique EMPTY que s'il n'est pas déclaréfinal (le JLS est spécifique sur ce point). Cependant, c'est définitif, donc il n'initialisera pas la classe.org.apache.commons.lang3.StringUtils.EMPTY

Voir une réponse connexe sur l'internement de chaînes et sur l' initialisation de classe , se référant au JLS 12.4.1 .

Matthieu
la source
«Seulement s'il n'est pas déclaré définitif», donc puisque ce champ est déclaré définitif, son accès ne peut pas provoquer l'initialisation de la StringUtilsclasse.
Holger
@Holger c'était une déclaration générale mais en effet, j'ai édité avec un lien vers le javadoc montrant qu'il est final (et donc n'initialise pas la classe).
Matthieu
8

Je n'aime pas vraiment l'utiliser, car return "";c'est plus court que return StringUtils.EMPTY.

Cependant, un faux avantage de son utilisation est que si vous tapez return " ";au lieu de return "";, vous pouvez rencontrer un comportement différent (si vous testez correctement une chaîne vide ou non).

Romain Linsolas
la source
13
Avez-vous déjà observé que c'était un problème (en utilisant accidentellement "" là où vous vouliez dire "")? Personnellement, je trouve le littéral plus lisible, et cela ne m'a jamais posé de problèmes.
Jon Skeet
2
@Jon Non, en effet, mais j'ai essayé de trouver un avantage à l'utiliser;)
Romain Linsolas
1
Il n'y a pas de règle de temps égal. S'il n'y a pas d'avantage, alors il n'y a aucun avantage.
Erick Robertson
1
Je n'aime pas non ""plus, je déteste taper la même chaîne littérale plus d'une fois, même une seule fois parfois. Je préfère déclarer les constantes dans Constants.java , mais ne pas les répéter partout dans le code source.
賈 可 Jacky
2
JE PENSE que return ""; c'est moche, je préfère utiliser return StringUtil.EMPTY(déclaré dans ma propre classe StringUtil , PAS StringUtils d'Apache ).
賈 可 Jacky
5

Si votre classe n'utilise rien d'autre des communs, il serait dommage d'avoir cette dépendance uniquement pour cette valeur magique.

Le concepteur de StringUtils fait un usage intensif de cette constante, et c'est la bonne chose à faire, mais cela ne signifie pas que vous devez également l'utiliser.

cherouvim
la source
Je voulais dire que c'est acceptable puisque l'auteur a choisi de suivre cette voie (éviter toute utilisation de "valeurs magiques"). Cela devrait être privé cependant.
cherouvim
L'auteur utilise fréquemment 0 dans le code. Aurait-il été préférable pour eux de définir également une constante int ZERO = 0? Sinon, quelle est la différence?
Jon Skeet
6
Ça dépend du contexte. S'il s'agissait d'un FCKEditorStringUtils, leur EMPTY serait "<p> & nbsp </p>" et je préférerais voir EMPTY réutilisé au lieu de répliquer cette valeur magique partout dans la classe. Donc, par EMPTY, ils signifient probablement EMPTY_CONTENT et non EMPTY_STRING (donc votre exemple ZERO est un peu injuste). Ne réutiliseriez-vous pas une constante ERROR_VISA_INVALID = 0?
cherouvim
1

Honnêtement, je ne vois pas grand-chose à utiliser. Si vous voulez comparer par exemple une chaîne vide, utilisez simplementStringUtils.isNotEmpty(..)

Bozho
la source
2
StringUtils.isNotEmpty(..)fait également un contrôle nul, donc ce n'est pas exactement la même chose que la comparaison avec une chaîne vide.
cherouvim
et comment allez-vous campare null? comme deuxième argument de equals, mais le résultat sera le même -false
Bozho
isNotEmptyest l'opposé de "".equals(…), par conséquent, le fait qu'il traitera nullcomme une chaîne vide est différent de comparer avec une chaîne vide, "".equals("")→ true, "".equals(null)→ false, StringUtils.isNotEmpty("")→ false, StringUtils.isNotEmpty(null)→ false. Si vous voulez juste savoir si une chaîne est vide, utilisez string.isEmpty(), qui a le bon comportement de retour truesi c'est une chaîne vide et de lancer un NullPointerExceptionsi la chaîne est null…
Holger
1

Je trouve StringUtils.EMPTYutile dans certains cas pour la lisibilité. Particulièrement avec:

  1. Opérateur ternaire, par exemple. 

    item.getId() != null ? item.getId() : StringUtils.EMPTY;
  2. Renvoyer une chaîne vide d'une méthode, pour confirmer que oui, je voulais vraiment faire cela.

En utilisant également une constante, une référence à StringUtils.EMPTYest créée. Sinon, si vous essayez d'instancier le littéral String à ""chaque fois, la JVM devra vérifier s'il existe déjà dans le pool String (ce qui sera probablement le cas, donc pas de surcharge de création d'instance supplémentaire). L'utilisation StringUtils.EMPTYévite sûrement la nécessité de vérifier le pool de chaînes?

À M
la source
4
Votre argument avec les multiples recherches ne tient pas. Dans le chapitre 13.4.9 de la spécification du langage Java 3.0, il est mentionné que la StringUtils.EMPTYconstante est résolue au moment de la compilation.
Roland Illig
4
L'existence dans le pool de chaînes est vérifiée au moment de la compilation et du chargement de la classe, pas au moment de l'exécution à chaque fois que vous exécutez une telle instruction,
Marquis of Lorne
1
Puisqu'il StringUtil.EMPTYs'agit d'une constante de compilation, une référence à celle-ci est compilée exactement avec le même bytecode que l'utilisation ""directe. De plus, je ne vois pas pourquoi l'opérateur ternaire devrait faire une différence. C'est une expression comme les autres. Toute raison d'utiliser ou de ne pas utiliser une constante nommée s'applique également à l'opérateur ternaire.
Holger
1

Non, car j'ai plus à écrire. Et une chaîne vide est vide indépendante de la plate-forme (en Java).

File.separator est meilleur que "/" ou "\".

Mais fais comme tu veux. Vous ne pouvez pas obtenir une faute de frappe commereturn " ";

Christian Kuetbach
la source
7
Je ne comprends pas du tout pourquoi la plupart des programmeurs ont si peur d'écrire «trop». En écrivant StringUtils.EMPTY, vous obtiendrez un code d'auto-commentaire, qui est plus facile à lire. Et selon Steve McConnell (ou une étude qu'il a citée dans Code Complete 2.0), le code est lu 7 fois plus qu'il n'est écrit.
Paweł Dyda
1
Vous avez particulièrement raison, MAIS: "" .equals (someString) est aussi facile à lire que StringUtils.EMPTY.equals (someString)
Christian Kuetbach
StringUtils.EMPTY.equals (someString) entraînera une erreur de syntaxe si vous l'écrivez de manière incorrecte. "" .equals (someString) ne le sera pas. C'est la seule raison pour laquelle il faut utiliser EMPTY.
Andrew T Finnell
1
@AndrewTFinnell, c'est pourquoi les programmeurs sensés écrivent à la someString.isEmpty()place.
Holger
-2

Oui, cela a du sens. Ce n'est peut-être pas la seule façon de procéder, mais je ne vois pas grand-chose à dire que «cela n'a pas de sens».

À mon avis:

  • Il ressort plus que "".
  • Cela explique que vous vouliez dire vide et que ce blanc ne fera probablement pas l'affaire.
  • Il faudra toujours changer partout si vous ne définissez pas votre propre variable et ne l'utilisez pas à plusieurs endroits.
  • Si vous n'autorisez pas les littéraux de chaîne gratuits dans le code, cela aide.
Oron
la source
It will still require changing everywhere if you don't define your own variable and use it in multiple places.vous allez changer une chaîne vide en une chaîne vide différente?
Pita
@Pita Désolé, c'était une mauvaise formulation. Je voulais dire que si vous utilisez cette fonction en ligne au lieu de "", vous n'obtenez toujours pas les mêmes avantages que la définition de votre propre constante et la réutilisation à plusieurs endroits. Ce n'est pas un argument pour StringUtils.EMPTY, c'est une explication que vous n'obtenez pas grand-chose même si cela «a du sens». Personnellement, je créerais une constante avec un nom descriptif, puis je l'attribuerais. J'ai vu quelques cas où un développeur voulait un seul espace et s'est retrouvé avec une chaîne vide, ce qui ne se produit pas avec ce formulaire.
Oron