La concaténation avec une chaîne vide pour effectuer une conversion de chaîne est-elle vraiment si mauvaise?

Question

Disons que j'ai deux char variables, et plus tard je veux concaténer une chaîne de caractères. C'est la façon dont je le ferais:

char c1, c2;
// ...

String s = "" + c1 + c2;

J'ai vu des gens qui disent que l' "" + "truc" est "moche", etc, et que vous devez utiliser String.valueOf ou Character.toString à la place. Je préfère cette construction parce que:

• Je préfère l'utilisation d'une langue plutôt la fonction d'appel d'API si possible
  • En général, n'est pas la langue généralement plus stable que l'API?
  • Si le langage ne cache appel d'API, puis encore plus forte raison de le préférer!
    • De plus abstrait! Le masquage est bon!
• J'aime que l' c1 et c2 sont visuellement sur le même niveau
  • String.valueOf(c1) + c2 suggère quelque chose de spécial à propos de c1
• C'est plus court.

Est-il vraiment un bon argument pourquoi String.valueOf ou Character.toString est préférable d' "" +?

---

Anecdote: en java.lang.AssertionError, la ligne suivante apparaît 7 fois, chacun avec un type différent:

    this("" + detailMessage);

Answer 1

Vos arguments sont bons; c'est l'un des plus expressifs les zones du langage Java, et l' "" + idiome semble bien ancrée, comme vous l'avez découvert.

Voir la concaténation de Chaîne dans le JLS. Une expression comme

"" + c1 + c2

est équivalent à

new StringBuffer().append(new Character(c1).toString())
                  .append(new Character(c2).toString()).toString()

sauf que tous les objets intermédiaires ne sont pas nécessaires (donc l'efficacité n'est pas un motif). La spec dit qu'une application peut utiliser l' StringBuffer ou pas. Depuis cette fonctionnalité est intégrée à la langue, je ne vois pas de raison d'utiliser le plus prolixe forme, surtout dans un marché déjà détaillé de la langue.

Answer 2

Le problème avec cette construction est qu'elle n'a généralement pas d'exprimer l'intention.

Il représente la concaténation d'une Chaîne par une autre valeur, mais la concaténation n'est généralement pas le but de cette ligne.

Dans le cas particulier qui vous l'a démontré, la concaténation est en fait l'objectif, de sorte que ce code n' exprimer l'intention.

Dans l'utilisation plus fréquente de cette approche (String s = "" + intValue;), la concaténation est simplement toléré côté-effet, tandis que la conversion de intValue est l'objectif réel. Et un simple String.valueOf(intValue) exprime l'intention beaucoup plus claire.

Answer 3

Je préfère utiliser String.valueOf pour les conversions simples - mais dans votre cas, vous voulez vraiment la concaténation.

Cependant, je suggérerais que cette version éliminerait toute ambiguïté potentielle:

 String s = c1 + "" + c2;
 

De cette façon, il n’ya aucune possibilité, aussi éloignée soit-elle, que quelqu'un se demande si c1 et c2 seront additionnés avant la concaténation.

Answer 4

Je pense que dans "" + var le + est effectivement surchargé pour faire la conversion:

Le langage Java fournit un soutien spécial pour l'opérateur de concaténation de chaîne ( + ), et pour la conversion des autres objets à cordes. La concaténation de chaîne est mise en œuvre par le StringBuilder(ou StringBuffer) de la classe et de sa méthode append. Chaîne de conversions sont mis en œuvre par le biais de la méthode toString, défini par l'Objet et héritées par toutes les classes en Java. Pour plus d'informations sur la concaténation de chaîne et de conversion

Donc pas de différence et pas de problème à partir d'un point de vue technique.

Former une lisibilité point de vue - c'est une question de préférence personnelle ou convenu style de codage au sein de l'équipe.

Answer 5

À mon avis, "" + x est très lisible, court et précis pour le moment. Je préfère ça à plus construit comme String.valueOf. Le comportement est bien défini et il est donc communément en usage que j'ai du mal à appeler cela un hack à tous.

La seule chose que je serais un peu inquiet au sujet de la performance et je suis très positif qu'il n'est pas question d'habitude (même si je n'ai pas de mesurer ou de regarder le binaire). Il ya aussi une bonne chance que ce genre de concat est optimisée, car il devrait être facile de le détecter (c'est juste une supposition bien).