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.

[tchize_]

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

Bulbo

Vu la tournure que ça prend, je crois qu'on peux te décerner un troll award là

[JoeChip]

Bon, on s'égare. Voici mon point de vue.

En fait, quand je refactorise, mon repère principal c'est le nombre de "mots". Je refactoriserait donc A en B. C'est certain. Peut-être est-il considéré par certains qu'il faudrait refactoriser B en A, mais alors pourquoi ne pas refactoriser jusqu'à l'explicite intégral de Tchize ? C'est une vraie question, dont la réponse m'intéresse vraiment.

Le rapport avec le rasoir d'Occam etc, c'est que j'ai lu il y a quelques mois un article sur les suites aléatoires et leurs rapports avec la complexité et la densité d'information etc, qui m'a rappelé ce travail constant de refactorisation, et qui faisait allusion au rasoir d'Occam comme un genre de proto-énoncé basé sur cette théorie de la complexité. Je n'arrive pas à remettre la main dessus, mais ça devrait intéresser tout le monde.

PS ce n'est pas un concours sur qui connaît le mieux le rasoir d'Occam, parce qu'il faudrait d'abord être d'accord sur la manière de mesurer cette connaissance.

[JoeChip]

Sans déconner, c'est quelque part là-dedans : http://scholar.google.fr/scholar?q=g...0%2C5&as_vis=1

Il est fait allusion à tout ça dans http://www.lifl.fr/SMAC/publications...nil-chavez.pdf page 19, 0.2
Enfin bon, vous devriez pouvoir trouver des trucs intéressants là-dedans.

[thelvin]

Toutes choses sont égales par ailleurs

Trois fois. C'est le nombre de fois dans cette discussion où j'ai montré que toutes choses ne sont pas égales par ailleurs.

Tu continues d'affirmer le contraire, et à ce jour tu n'as jamais rien montré en ce sens. C'est pourtant la seule chose qui ait jamais disputée ici en rapport avec la question d'origine.

Peut-être est-il considéré par certains qu'il faudrait refactoriser B en A, mais alors pourquoi ne pas refactoriser jusqu'à l'explicite intégral de Tchize ?

L'exemple de tchize_ n'est pas explicite du tout, sans même parler d'un explicite "intégral."
L'idée est de vérifier si deux mots sont les mêmes et de ne pas faire d'erreur en cas de null. Pas de vérifier si le tableau des caractères d'un mot, est le même qu'un tableau de caractères qui serait composé des lettres dans l'ordre d'un autre mot (en évitant au passage de faire une erreur en cas de null).

J'ignore si tchize_ se moquait de moi et de ma défense de la valeur de l'explicite, ou des opposés qui manifestement ne comprenaient pas ce que veut dire explicite, ou de tout le monde. Mais il a mis un exemple explicitant à la machine ce qui doit être vérifié dans le modèle mathématique de la mémoire.
Il est évident depuis le début qu'en parlant d'intention explicite, il ne s'agissait absolument pas d'être explicite pour la machine, mais pour l'humain. De faire en sorte que l'humaine sache immédiatement ce qu'on cherche à faire.

C'est une vraie question, dont la réponse m'intéresse vraiment.

Et donc, la valeur d'avoir B plutôt que A, c'est que l'intention est immédiatement claire. C'est ce que veut dire le mot explicite. (Personnellement ça ne me convaincrait pas pour autant de refactoriser.)
Le code de tchize_ étant illisible, le même raisonnement ne peut pas y être appliqué.

[JoeChip]

Bah c'est insoluble, pour moi la perception de l'intention est immédiate pour B : on regarde si s est égal à "abcd". Pourquoi on traiterait particulièrement du cas ou s est null, puisque c'est pareil à tous les autres cas où s n'est pas égal à "abcd". J'aurais pu aussi bien dire on regarde si "abcd" est égal à s, mais justement, la petite différence avec le langage naturel indique quelque chose, qui est que le null est géré.

[bulbo]

Vu la tournure que ça prend, je crois qu'on peux te décerner un troll award là

En même temps j'avais prévenu dés le début que c'était taquinerie vendredesque je ne m'attendais pas à une telle empoignade philosophique.

En plus c'est balot j'avais fini mes chips

Bon je vais mettre ce sujet en résolu avant que le rasoir d'Occam finisse dans la main d'un de nos protagonistes.. la loi est sévère avec ça, peu importe le petit nom du rasoir d'ailleurs. (Ah on me souffle dans l'oreillette qu'il y a une tolérance pour Ginette)

Pour départager .. personne .. je dirais qu'entre les deux expressions il y a belle est bien une différence de complexité, vu le niveaux (en java) des trolleurs de ce topic, ça nous semble évident mais croyez moi ça ne l'est pas.

Le test sur null tel qu'écrit et parenthésé repose sur une règle supplémentaire et loin d'être anodine, la priorité des opérateurs logique.
Mon expérience m'a bien souvent montré qu'en cas de maintenance le copié/collé est le design pattern le plus souvent utilisé.

Et pour moi le soucis de l'écriture avec le test sur null c'est qu'en lecture rapide, le parenthésage ne vous saute pas au visage pour vous mordre le nez. Donc à moins de s'arrêter explicitement sur ce if pour le lire attentivement, il est fort probable que ce if mal modifié s'il n'est pas testé parte en production.
Le pire c'est qu'on ne peut même pas prévoir un parenthésage "de sureté", il faut vraiment espérer que la personne qui devra le modifier un jour pense à ça.

Bon demain je me poserai la question de savoir si (null == toto) est meilleure que (toto == null) .. ça risque d'être saignant prévoyez les pansements.

Bulbo

[thelvin]

De toute façon, à partir du moment où on met des parenthèses, la question n'est plus la même.

Mais oui, et alors ? Ça ne change rien au reste.

[JoeChip]

Les parenthèses ça complique tout !

[rg77140]

Bonjour,

Pour allier robustesse et lisibilité je préfère utiliser, dans tous les cas (que ça soit pour comparer une constante à une variable ou deux variables entre elles) , la classe StringUtils de d'Apache:

Code :

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

1
2
3
if(StringUtils.equals(x,"abcd")){
 
}

Avec un import static ça donne :

Code :

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

1
2
3
4
5
6
import static org.apache.commons.lang3.StringUtils.equals;
...
 
if(equals(x,"abcd")){
 
}

Si jamais le client interdit d'utiliser les librairies Apache (oui oui c'est du déjà vu...), alors j'opte pour "abcd".equals(x), plus robuste et moins complexe.