Version imprimable
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:
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é.Code:"abcd".equals(maString)
Apparemment cette écriture à des détracteurs, alors messieurs, à vos stylos.. enfin clavier quoi ;)
Bulbo ;)
Ça fait référence à :
Versus :Code:
2
Sachant qu'on aura sans doute soit :Code:
2
* "abcd" en constante ;
* une valeur dynamique de comparaison.
En constante :
Ou en dynamique :Code:
2
3
4
5
Notez que dans ce dernier cas, on n'est pas obligé de tester la nullité de "s".Code:
2
3
4
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).
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:
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..Code:public static final String ABCD = "ABCD";
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 :)Citation:
Envoyé par JoeChip
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.
Ce n'est pas juste de la sémantique ! C'est de la SEMANTIQUE MOTHER FUCKER !Citation:
"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
Nan sans blague, c'est vraiment important.
Ça fait quoi au niveau de la JVM ça ? hein ? hein ?Citation:
Je trouve personellement "abcd".equals() plus robuste et court à lire.
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.
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.
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.
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 :
est équivalent àCode:
2
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:
2
Vous voyez l'intervalle dans l'exemple ?Code:
2
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.
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.Citation:
Envoyé par thierryler
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.Citation:
Envoyé par JoeChip
Aucune de ces deux remarques n'est plus importante que l'autre par nature.
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 !
Je serais curieux de connaitre ces différences... mais je doute que cela puisse avoir un impact quelconque.Citation:
Envoyé par thierryler
a++
C'est surtout un poil biaisé comme exemple, equals est censé être une bijection alors que > non.Citation:
Envoyé par thierryler
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 :)
C'est dégueulasse. Tu leur a retiré la moitié des smiley possibles :mrgreen:Citation:
Envoyé par thierryler;7530816
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
On ne peux plus faire le petit chat avec ses oreilles et sa moustache
>3
mais on peux toujours faire les coeurs
<3
C'est a < b qu'il faut comparer à b > a !!!!
Sinon, je préfère avoir des cœurs ;-)
L'autre écriture n'est pas plus safe, exemple rencontré récemment au taf.Citation:
Envoyé par thelvin
Expression originale:
On demande à un programmeur inexpérimenté (on va rester poli :) ) de rajouter un OR str.equals("BUSY").Code:if ((str != null) && str.equals("ABCD"))
Bah là on a rien refactorisé..et on a un NullPointer des familles.Code:if ((str != null) && str.equals("ABCD") || str.equals("BUSY"))
On n'empêchera pas les âneries par une écriture .. mais là le mieux est l'ennemi du bien car:
Là pas de NPE :mrgreen:Code:if ("ABCD".equals(str) || "BUSY".equals(str))
Effectivement, ce dernier argument me fait changer mon fusil d'épaule...
Si maintenant tu pouvais en plus le pointer sur quelqu'un d'autre :ccool: :mouarf:Citation:
Envoyé par thierryler
Elle est bel et bien plus safe, mais comme toute chose de cet Univers, elle n'atteint pas la sûreté absolue, pas plus que son alternative.Citation:
Envoyé par bulbo
L'exemple que tu donnes évoque une erreur de parenthésage, ou de priorité des opérations suivant la manière dont on veut le voir.
C'est une erreur d'incompétence ou d'étourderie plus prononcée que le fait de ne pas avoir vu une vérification contre null qui est implicite de la mécanique du langage (au contraire du parenthésage qui ne relève que de la syntaxe enseignée depuis le primaire.)
Faut jamais faire ça. On commence par le changer d'épaule, du coup on tire comme une merde. Et c'est comme ça qu'on confond un immigré avec un Cerf pendant la chasse au canard.
En même temps que dire d'un développeur qui refactorise un code qui fonctionne ...
Règle numéro 1 du développeur: Si ça marche tu ne touches pas :mrgreen:
Et qui ne teste pas ensuite le résultat de son sabotage
Règle numéro 2 du développeur: toujours tester ce que l'on modifie.
Dans mon équipe ça traîne pas ce genre de chose, vu que j'applique la Règle n°9 du NCIS :twisted:
Tchize : En même temps si tu crois tirer sur un cerf dans une chasse au canard .. c'est pas d'épaule mais de lunettes qu'il faut changer :)
Bah non : moins il y a de mots, moins c'est compliqué... Et moins il y a de chemins, moins c'est compliqué. Avec le if il y a davantage de chemins et de mots, donc c'est objectivement plus compliqué.Citation:
Laquelle est plus compliquée que l'autre est une question d'opinion
Oui.Citation:
Envoyé par JoeChip
Non. Tu n'as pas fait la somme des effets. Tu as juste isolé un effet et considéré qu'il est négatif, donc le résultat final est négatif. Ça ne marche pas comme ça. Le résultat final est constitué de la somme de tous les effets. Ceux qui t'arrangent et ceux qui ne t'arrangent pas.Citation:
Envoyé par JoeChip
"moins il y a de mots, moins c'est compliqué" est une assertion correcte. Appelons-la l'assertion A.
Mais il y a une autre assertion pertinente : "plus c'est explicite, moins c'est compliqué." Appelons-la l'assertion B.
Tu as tenu compte de A, mais pas de B. C'est une préférence personnelle tout-à-fait recevable, mais une préférence, pas un fait, pas quelque chose d'objectif. A n'est pas intrinsèquement plus importante que B, ni l'inverse.
Il s'agit d'une question de préférence, qui dans ce cas simple et direct constitue aussi une opinion. En aucun cas quelque chose d'objectif.
Si je me souviens bien de mes cours d'algo, un algo est d'autant plus simple qu'il comporte peu de mots. De deux algo fonctionnant identiquement, le plus court est le meilleur. C'est la base de la théorie de la complexité, entre autre... C'est connu aussi sous le nom de "rasoir d'Occam" en ce qui concerne les théories scientifiques.
Ce qui est rendu implicite par le langage utilisé sert justement à diminuer la complexité des programmes. Dans le cas qui nous occupe, "abcd".equals(s)" est l'algo en Java pour "retourne true si s est égal à abcd". Tout ce qui serait rajouté augmente la redondance, sans diminuer la complexité.
Je ne sais pas où tu as vu que quand c'est explicite c'est moins compliqué. Car dans ce cas, le plus simple serait le plus explicite, donc ce qui compte le plus de mots, et du coup c'est le langage machine qui est le moins compliqué. Un langage de haut niveau sert à masquer la complexité grâce à des implicites...
Non. Le rasoir d'Occam décrit une conséquence concernant ce qui est le plus simple. En aucun cas une mesure de ce qui est plus simple qu'autre chose.Citation:
Envoyé par JoeChip
Tu confonds être explicite, et élaborer ou périphraser. Bien que c'est souvent en élaborant qu'on devient plus explicite, ce n'est pas nécessairement la seule méthode, et en fait c'est une qualité du langage ou du développeur, quand il est capable d'expliciter l'intention sans être plus verbeux pour le faire.Citation:
Envoyé par JoeChip
Dans l'exemple qui nous intéresse, oui, la vérification du pointeur null est un peu plus verbeuse, mais pas assez pour être un vrai inconvénient.
La valeur même du code court vient dans le fait qu'il est facile à prendre dans sa globalité, or le fait de l'expliciter sans le rallonger sensiblement, le rend justement plus rapide à comprendre.
Quant à où je l'ai vu, eh bien déjà c'est souvent cité comme bonne pratique. Ça se constate également au jour le jour, c'est efficace.
C'est le principe même que de bien nommer ses variables plutôt que "a" ou "b," ou que d'extérioriser en méthodes juste pour leur donner un nom, plutôt que d'une seule méthode qui reste courte mais fait beaucoup de choses à la fois, l'un des effets bénéfiques intrinsèques du principe de séparation des tâches : les tâches ont facilement un nom descriptif.
C'est l'application la plus directe de la règle "le code le mieux documenté est celui qui se décrit lui-même," l'une des bonnes pratiques retenues de commentaires de code.
C'est assez explicite? :)
Code:if (x !=null && Arrays.equals(char[] {'a','b','c','d'},x.toCharArray())
code A :
code B :Code:s != null && s.equals("abcd")
7 "mots" dans le code A, 3 dans le code B, et tu trouve ça un peu plus verbeux ? En gros, A est d'une complexité "brute" de plus de deux fois celle de B... Et le rasoir d'Occam dit que de deux codes, le plus court est le meilleur, tu crois quoi ? J'ai dit que le rasoir d'Occam mesurait quelque chose ? Au fait, c'est quoi ta définition de "conséquence" ?Code:"abcd".equals(s)
Non ! La complexité est plus liée aux nombres d'opérations en fonction de la taille des données à traiter et donc de l'évolution de la vitesse de traitement en fonction de cette taille.Citation:
Envoyé par JoeChip
Le nombre de mots n'a pas vraiment d'influence.
Concernant la lisibilité, la compréhension, etc., le nombre de "mot" intervient, mais pas uniquement tu as aussi, au moins, l'expressivité, l'explicite/implicite, la sémantique.
Sans compter les habitudes et une certaine subjectivité.
Le rasoir d'Occam dit ne pas introduire de nouvelles hypothèses tant que celles qu'on a suffisent à résoudre le problème. Ou en vulgarisant, que la solution la plus simple est souvent la bonne.Citation:
Envoyé par JoeChip
Il n'y a pas vraiment de notion de longueur.
Tu es trop sûr de toi, je n'invente rien, mais il faudrait que je remette la main sur mes sources. Tu semble croire que j'invente ce que je dis et que je ne connais pas la mesure de complexité liée au temps de calcul. Il faut que je remette la main sur ma source sur la théorie de la complexité, liée notamment aux suites aléatoires, et pas uniquement à celle vue par un ingénieur en informatique. En gros on peut définir la complexité par l'"aléatoirité", et on peut mesurer le caractère aléatoire d'une suite en mesurant sa compressibilité. On ne parle pas juste d'informatique, là. C'est plus général, mais ça inclus l'informatique, bien entendu.
D'ailleurs, tu peux avoir un algo simple dont le temps de calcul augmente en n! ou un algo compliqué qui augmente linéairement le temps de calcul (exemple : la recherche de nombres premiers).
Et de toutes façons, ce que je dis sur la complexité comparée de A et de B reste vrai.Quant à prétendre que la longueur et la simplicité ne sont pas corrélées...
Oui. Parce que s'il est vrai qu'en taille relative, l'un d'eux est deux fois plus long que l'autre (le nombre d'éléments n'est pas intéressant dans le détail : il y a une ou deux conditions vérifiées, et elles sont simples ; )Citation:
Envoyé par JoeChip
toujours est-il qu'en taille absolue, les deux restent assez courts et simples pour être vus et compris immédiatement. La différence de taille relative n'est donc pas un point fort de comparaison.
Je crois que tu es mythomane. Car, comme gentiment rappelé au-dessus, le rasoir d'Occam ne dit tout simplement rien de ce genre, et il n'y pas franchement moyen de confondre.Citation:
Envoyé par JoeChip
"Mesurer" n'est peut-être pas le mot, mais "comparer," alors. Ce n'est pas le cas. Le rasoir d'Occam ne sert pas à comparer deux choses, mais à tirer une conclusion une fois qu'elles l'ont été.Citation:
Envoyé par JoeChip
Euh... "Effet" dans une relation de cause à effet ? Le rasoir d'Occam permet essentiellement de tirer une conclusion lorsque parmi plusieurs "éléments" a été déterminé, par un moyen qui n'a rien à voir avec le rasoir d'Occam, lequel est le plus "simple." Le rasoir d'Occam conclut que c'est le plus probablement lui qui est correct.Citation:
Envoyé par JoeChip
donc, pour toi, le rasoir d'Occam décrit un effet concernant ce qui est le plus simple, ce qui contredit ma proposition qui dit que le rasoir d'occam est une application particulière d'une théorie de la complexité qui décrit la complexité en terme de nombre de mots nécessaires. Ok ok, logique tout ça.
De deux théories expliquant la même chose ( = deux algo produisant le même résultat), la moins complexe est la meilleure ( = l'algo décrit en le moins de mot est le plus simple). La complexité en termes de temps de calcul est un autre problème. Là on parle de complexité de la représentation. "Ta" représentation est deux fois plus complexe que l'autre, et ya pas à sortir de là, même si tu en arrive aux insultes à cause de ton manque de culture.
Donc bon, mytho c'est çui qui le dit qui l'est, faut lire un peu autre chose que des manuels d'informatique.
Non. Longue.Citation:
Envoyé par JoeChip
Si. Ça ne suffit pas pour conclure sur la complexité. "Ta représentation" est moins explicite. Tu peux décider autant que tu veux que ça ne compte pas, mais tu ne l'as jamais justifié, et je doute que ce soit justifiable.Citation:
Envoyé par JoeChip
Bis repetita, il y a deux assertions, A et B. Tu as passé ton temps à défendre A que personne n'a jamais contredit, tout en t'imaginant que ça allait envoyer B dans les limbes de l'inexistence. Ce n'est juste pas le cas.
"y a pas à sortir de là" n'est pas un argument.
J'en arrive aux "insultes" (mythomane ça veut dire mythomane) en réaction à ta condescendance parfaitement déplacée et au fait que tu aies plusieurs fois fait comme si des parties importantes de mon explication, je ne les avais pas dites, ce qui est extrêmement incivil.Citation:
Envoyé par JoeChip
Je sais être déplacé et incivil, moi aussi.
En l'occurrence le rasoir d'Occam n'a juste rien à voir avec l'informatique, et de nous, c'est toi qui le connaissais le moins bien.Citation:
Envoyé par JoeChip
Peu importe. Ce dont nous parlons ici est une bonne pratique informatique. Il n'y a pas d'intérêt à évoquer la culture hors informatique sur cette question.
C'est là que mon avis (et visiblement je ne suis pas le seul) diffère du tien.Citation:
Envoyé par JoeChip
Si, bien entendu, la longueur a une influence importante sur la simplicité, ce n'est pas, loin de là, le seul critère.
Certes si tous les autres critères sont égaux, la construction la plus courte sera probablement la plus simple à comprendre mais dans le cas contraire ? Un code plus court n'est pas forcément toujours plus simple (ne serait-ce que lorsque le code le plus court utilise une construction particulièrement confuse ou rare que l'on ne maitrise pas très bien).
Je sais que ce n'est pas un critère absolu. Mais dans le cas qui nous occupe, ça l'est. Toutes choses sont égales par ailleurs, si on tient compte du fait que tout programmeur sait que si a==b alors b==a. En plus je n'ai pas parlé que du nombre de mots, mais aussi du nombre de chemins.
Arf.Citation:
En l'occurrence le rasoir d'Occam n'a juste rien à voir avec l'informatique, et de nous, c'est toi qui le connaissais le moins bien.
Vu la tournure que ça prend, je crois qu'on peux te décerner un troll award là :mouarf:Citation:
Envoyé par bulbo
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. :ptdr:
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.