Discussion :

[bulbo]

Pour faire suite à cette discussion : http://www.developpez.net/forums/d13...s/#post7530394

Il se trouve que j'ai pris l'habitude de tester mes chaînes ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"abcd".equals(maString)

Naïvement je trouvais ça élégant, en plus de faire le boulot que je lui demande à savoir m'éviter une NullPointer et tester mon égalité.

Apparemment cette écriture à des détracteurs, alors messieurs, à vos stylos.. enfin clavier quoi

Bulbo

[thierryler]

Ça fait référence à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( "abcd".equals(value) ) {

Versus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( value != null && value.equals("abcd") ) {

Sachant qu'on aura sans doute soit :
* "abcd" en constante ;
* une valeur dynamique de comparaison.


En constante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
final static public String ABCD = "abcd";
...
 
if( value != null && value.equals(ABCD) ) {

Ou en dynamique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
String s = ...
 
if( value != null && value.equals(s) ) {

Notez que dans ce dernier cas, on n'est pas obligé de tester la nullité de "s".

Il y a des différences :
* sémantiquement ;
* dans le plan d’exécution de la JVM (là je vais être un peu léger pour en discuter longtemps).

[bulbo]

Pour préciser mon propos, je n'utilise cette écriture que lorsque je dois comparer avec une constante soit une chaine constante "ABCD" soit une constante java déclarée ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public static final String ABCD = "ABCD";

Sans aller jusqu'au plan d’exécution de la JVM et dans les use cases décrit juste au dessus, j'ai un peu de mal à voir la différence sémantique..

Bulbo

[JoeChip]

Amha moins il y a de mots, mieux c'est (théorie de la complexité), donc ta solution est pour moi la meilleure.

[bulbo]

Amha moins il y a de mots, mieux c'est (théorie de la complexité), donc ta solution est pour moi la meilleure.

Même si j'ai du mal avec leur déguisements, j'applique le principe du KISS dans mes développement: Keep It Simple and Stupid

[tchize_]

Il est plus naturel (point de vue humain) de dire

"Si la variable X vaut ABCD" que de dire "Si ABCD vaut la variable x". C'est juste de la sémantique. Ca ne vaut pas tripette comme argument


Autre arguments, quand je dit

x.equals("ABCD"), je refuse implicitment les cas où x égal à null comme des erreurs, et souvent on est face à une cas où une variable nulle n'a pas de sens et il est bon de lancer une erreur. Maintenant, ça vaut pas tripette non plus comme argument.

Je trouve personellement "abcd".equals() plus robuste et court à lire.

[thierryler]

"Si la variable X vaut ABCD" que de dire "Si ABCD vaut la variable x". C'est juste de la sémantique. Ca ne vaut pas tripette comme argument

Ce n'est pas juste de la sémantique ! C'est de la SEMANTIQUE MOTHER FUCKER !

Nan sans blague, c'est vraiment important.

Je trouve personellement "abcd".equals() plus robuste et court à lire.

Ça fait quoi au niveau de la JVM ça ? hein ? hein ?

[bulbo]

La méthode equals étant une bijection, je ne vois pas bien en quoi a.equals(b) pourrait bien différer de b.equals(a) niveau sémantique.

Ensuite pour ce que la JVM fait dans ce cas, elle initialise un objet String qu'elle place dans la Stack pour l'appel.. en gros ce qu'elle fait également lorsque la constante est en paramètre du equals.. en gros pour moi du kif kif.

Après si on prend les sorties des 2 statements, on a du 100% identique. D'ailleurs cette écriture est régulièrement conseillée dans des documents de 'coding standard'

Après si la FUCKING différence de sa mère la sémantique c'est de ne pas lire explicitement le test de null dans le programme.. ce n'est pas, à mon sens, de la sémantique mais de la syntaxe.

La sémantique des deux écritures est:

Compare les 2 strings et si jamais a est nulle retourne faux.

[JoeChip]

Sémantiquement c'est complètement équivalent, à la nuance près que le cas "s==null" est implicitement traité comme il le doit dans "abcd".equals(s)", càd comme tout autre cas où l'égalité n'est pas vérifiée. Et de toutes façons, pour écrire en plus de trois mots un truc "écrivable" en trois mots, faut des arguments puissants.

[thelvin]

Il y a la sémantique de définition de l'algorithme Java, et il y a la sémantique d'expression de l'intention.
Ce sont deux choses différentes.

En termes d'algorithme, les deux notations n'ont pas de différence.
Une légère différence théorique du temps d'exécution dans le fait que vérifier si un objet est null, est en théorie un peu plus rapide qu'invoquer une méthode. Avec les optimisations du JIT je n'y mettrais pas ma main à couper.

En terme d'expression d'intention, l'une des notation indique explicitement qu'on vérifie si la non-constante est null. L'autre notation laisse cela à la déduction des programmeurs qui connaissent le truc, et montre une syntaxe bizarre aux autres, qui au premier refactoring vont inverser les deux objets, sans vérification de null, cette fois.

[thierryler]

Non non non, ça a beau donner le même résultat, c'est très différent...

Je vous donne un exemple qui sera plus parlant. Prenons un entier nb et comparons le à une valeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( nb > 42 ) {

est équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( 42 < nb ) {

Et ben non, pas du tout : le sens de lecture n'est pas le même dans les deux cas. Voici pourquoi j'oblige mon équipe à utiliser le second cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( 42 < nb && nb < 91) {

Vous voyez l'intervalle dans l'exemple ?

C'est pareil pour les strings.

Quand je fais "abcd".equals(s) je compare "abcd" à s. Quand je fais s.equals("abcd") je compare s à "abcd"... Au final le résultat est le même mais le sens de lecture est différent.

Pour la partie JVM, je vous laisse voir ça avec un spécialiste qui saura vous expliquer mieux que moi ce qui se passe, non pas en Java, mais dans la virtual machine.

[thelvin]

Pour la partie JVM, je vous laisse voir ça avec un spécialiste qui saura vous expliquer mieux que moi ce qui se passe, non pas en Java, mais dans la virtual machine.

Je suis suffisamment expert sur le sujet pour savoir que ce qui se passe ne démontre aucune différence notable. Deux ou trois instructions de plus ou de moins qui seront sans doute mises à niveau par le JIT, et qui de toute façon ne sont pas représentatives du temps d'exécution de l'ensemble.

[JoeChip]

N'empêche que dans ce cas particulier, je trouve que c'est le mieux. Refactoriser ça aveuglément bah oui ça bugge comme toujours quand on refactorise aveuglément (et en l'occurrence sans gain)... Et considérer qu'il s'agit d'un "truc", c'est un drôle de point de vue. Pour les exemples plus compliqués, en revanche, je suis d'accord... Mais dans ce cas-ci c'est tellement limpide et simple que je ne vois pas ce qui justifierait une complexification des sources.

[thelvin]

N'empêche que dans ce cas particulier, je trouve que c'est le mieux. Refactoriser ça aveuglément bah oui ça bugge comme toujours quand on refactorise aveuglément (et en l'occurrence sans gain)... Et considérer qu'il s'agit d'un "truc", c'est un drôle de point de vue. Pour les exemples plus compliqués, en revanche, je suis d'accord... Mais dans ce cas-ci c'est tellement limpide et simple que je ne vois pas ce qui justifierait une complexification des sources.

Laquelle est plus compliquée que l'autre est une question d'opinion, pas un fait. Une notation est explicite, l'autre non. Une notation est très courte, l'autre est assez longue et un peu lourdingue.
Aucune de ces deux remarques n'est plus importante que l'autre par nature.

[adiGuba]

Salut,


Perso j'ai tendance à utiliser la forme "x".equals(s) simplement pour simplifier la condition et éviter d'écrire une vérification supplémentaire vis à vis du null.

A l'inverse si s ne devrait jamais être null, j'aurais tendance à utiliser directement s.equals("x") pour laisser remonter un NPE au plus tôt !

Pour la partie JVM, je vous laisse voir ça avec un spécialiste qui saura vous expliquer mieux que moi ce qui se passe, non pas en Java, mais dans la virtual machine.

Je serais curieux de connaitre ces différences... mais je doute que cela puisse avoir un impact quelconque.


a++

[bulbo]

Je vous donne un exemple qui sera plus parlant. Prenons un entier nb et comparons le à une valeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( nb > 42 ) {

C'est surtout un poil biaisé comme exemple, equals est censé être une bijection alors que > non.

a.equals(b) == b.equals(a)

(a > b) != (b > a)

Je n'ai parlé que du equals à dessein, je n'utilise pas ce raccourci pour les comparaisons.. ça me vrille les neurones pour tout remettre dans le bon sens et pour vérifier la logique

[tchize_]

if( 42 < nb && nb < 91) {
[/code]

C'est dégueulasse. Tu leur a retiré la moitié des smiley possibles

On ne peux plus faire le petit chat avec ses oreilles et sa moustache
>3

mais on peux toujours faire les coeurs
<3

[thierryler]

C'est a < b qu'il faut comparer à b > a !!!!

Sinon, je préfère avoir des cœurs ;-)

[bulbo]

En terme d'expression d'intention, l'une des notation indique explicitement qu'on vérifie si la non-constante est null. L'autre notation laisse cela à la déduction des programmeurs qui connaissent le truc, et montre une syntaxe bizarre aux autres, qui au premier refactoring vont inverser les deux objets, sans vérification de null, cette fois.

L'autre écriture n'est pas plus safe, exemple rencontré récemment au taf.

Expression originale:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ((str != null) && str.equals("ABCD"))

On demande à un programmeur inexpérimenté (on va rester poli ) de rajouter un OR str.equals("BUSY").

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ((str != null) && str.equals("ABCD") || str.equals("BUSY"))

Bah là on a rien refactorisé..et on a un NullPointer des familles.

On n'empêchera pas les âneries par une écriture .. mais là le mieux est l'ennemi du bien car:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ("ABCD".equals(str) || "BUSY".equals(str))

Là pas de NPE

[thierryler]

Effectivement, ce dernier argument me fait changer mon fusil d'épaule...