Lorsque vous comparez une variable chaîne à un littéral chaîne avec .equals (), existe-t-il une pratique standard pour l'ordre des éléments? [fermé]

11

Il y a des avantages pour chacun et je comprends les différences, mais qu'est-ce qui est considéré comme la meilleure pratique / la pratique standard? Et pourquoi?

Par exemple :

"myString".equals(myStringVar)
  • Évite un NPE potentiel et ne nécessite pas de vérification nulle. (Bonne chose?)
  • Nettoyant à lire car une vérification nulle n'est pas requise.
  • Si null n'est pas une valeur attendue, votre programme pourrait se casser sans être le plus sage.

pourtant 

myStringVar.equals("myString")
  • Nécessite une vérification nulle si null est une valeur attendue. (Bonne chose?)
  • Peut encombrer les conditionnels composés avec des contrôles nuls.
  • Permet à NPE de nous faire savoir si quelque chose s'est cassé.

Quelle variante est considérée comme la norme à utiliser pour Java, et pourquoi?

java programming-practices coding-standards BrandonV
la source
2
Que null soit une valeur attendue ou non, l'opération «égal» devrait-elle être le lieu pour déterminer que c'est un problème?
Matthew Flynn
Je ne pense pas. Mais cela est mon opinion. J'aimerais entendre la justification des autres.
BrandonV
Dans les langues qui utilisent = et / ou == pour les affectations / comparaisons, il est normalement préférable de mettre la chose qui ne peut pas changer à gauche afin que vous ne puissiez pas effectuer une affectation accidentelle lorsque vous vouliez faire une comparaison. Pour les langages qui utilisent des méthodes sur un objet comme .equals, je ne pense pas que cela soit important.
GordonM

Réponses:

3

Je soupçonne que cela provient d'une précaution de sécurité utilisée lors de la programmation en C plus ancien (ou C ++). En C, vous pouvez accidentellement affecter une valeur lorsque vous souhaitez tester l'égalité:

if (x = 3)

Cette condition sera toujours vraie, car sa valeur xa d'affectation est de 3, et ne teste pas que x est égal à 3. Pour éviter ces bogues subtils, les développeurs ont commencé à inverser la condition:

if (3 = x)

Cela contient le même "bug", mais générera une erreur de compilation, donc c'est plus sûr.

Les langues plus modernes n'ont pas ce problème, et elles peuvent facilement vous avertir lorsque vous essayez de faire ce genre de choses. En tant que tel, ce n'est pas une préférence à peu près pure, alors choisissez-en une et utilisez-la de manière cohérente.

Oleksi
la source
-1 Ce n'est pas la raison de la convention Java pour equals. Contrairement à C, le problème pour Java est que l'expression x.equals(y)lancera un NPE lorsqu'il xest nul. Si vous avez un littéral String "something"et que vous souhaitez considérer le cas nullcomme "différent de", il est logique d'écrire "something".equals(y)si vous ne savez pas s'il ypeut être nul. Cela ne lancera jamais de NPE.
Andres F.
1

  • La norme et les bonnes pratiques varient selon la culture d'une organisation pour laquelle vous travaillez

  • Notre norme en .NET est myStringVar == "myString"simplement parce que nous nous y sommes mis d'accord, c'est-à-dire que nous pensons qu'il est propre et concsice

Remarque: Cela ne s'applique pas à Java en raison de la ==comparaison des références au lieu des objets eux-mêmes. En Java, vous devriez utiliser myStringVar.equals("myString").

CodeART
la source
3
Au moins en Java, ne l'utilisez pas ==car il compare uniquement les références d'objets. Cela dit, +1 pour le setiment - convention définit souvent la "bonne" façon de faire les choses.
Michael K
Merci de l'avoir signalé! J'ai mis à jour la réponse :)
CodeART
@CodeWorks: Je pense que vous avez manqué le point de Michael. De plus, c'est Java et non JAVA.
amara
La question était: "mais qu'est-ce qui est considéré comme la meilleure / pratique standard? Pourquoi?" Ma réponse est que la norme et les meilleures pratiques varient d'une organisation à l'autre. Êtes-vous en désaccord avec cela?
CodeART
@CodeWorks: Personne ne pourrait être en désaccord avec cela, CodeWorks. Mais tout le monde pourrait convenir que myStringVar == "myString"c'est une très mauvaise idée sur Java (à moins que vous ne soyez absolument certain d' myStringVarêtre interné).
amara
0

Je pense que vous avez raison en ce que cela dépend de la sémantique de nullité de la variable. Si vous ne vous attendez pas à ce qu'il soit nul et que vous n'ayez pas à le vérifier et à le gérer, le premier formulaire est plus propre.

Cela dit, plutôt que d'intégrer le littéral de chaîne, une meilleure option serait probablement la suivante:

private final String MY_STRING = "myString";
if(MY_STRING).equals(myStringVar);

Surtout s'il existe un potentiel d'utilisation de la chaîne à plusieurs endroits.

Benjamin Wootton
la source
2
-1: pas vraiment mieux; ajoute de l'encombrement avec une valeur généralement négligeable
amara
@sparkleshy - Pas d'accord, vous ne voulez vraiment pas que les littéraux de chaîne soient dispersés dans votre logique de code. Comme mentionné dans la réponse originale, si le littéral de chaîne est utilisé à plus d'un endroit, je dirais définitivement de les refactoriser.
Benjamin Wootton
Pour dire cela, vous devez dissiper complètement python, car en python, les identificateurs SONT essentiellement des littéraux de chaîne. Et je pense que nous devons tous convenir que le python est un bon langage.
amara