Discussion :

[bulbo]

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

Si maintenant tu pouvais en plus le pointer sur quelqu'un d'autre

[thelvin]

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

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.

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.)

[tchize_]

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.

[bulbo]

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

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

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

[JoeChip]

Laquelle est plus compliquée que l'autre est une question d'opinion

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é.

[thelvin]

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,

Oui.

donc c'est objectivement plus compliqué.

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.

"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.

[JoeChip]

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...

[thelvin]

C'est connu aussi sous le nom de "rasoir d'Occam" en ce qui concerne les théories scientifiques.

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.

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...

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.

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.

[tchize_]

C'est assez explicite?

Code :

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

if (x !=null && Arrays.equals(char[] {'a','b','c','d'},x.toCharArray())

[JoeChip]

code A :

Code :

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

s != null && s.equals("abcd")

code B :

Code :

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

"abcd".equals(s)

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" ?

[gl]

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...

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.
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é.

Et le rasoir d'Occam dit que de deux codes, le plus court est le meilleur, tu crois quoi ?

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.
Il n'y a pas vraiment de notion de longueur.

[JoeChip]

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...

[thelvin]

7 "mots" dans le code A, 3 dans le code B, et tu trouve ça un peu plus verbeux ?

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 ; )
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.

Et le rasoir d'Occam dit que de deux codes, le plus court est le meilleur, tu crois quoi ?

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.

J'ai dit que le rasoir d'Occam mesurait quelque chose ?

"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é.

Au fait, c'est quoi ta définition de "conséquence" ?

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.

[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.

[thelvin]

"Ta" représentation est deux fois plus complexe que l'autre,

Non. Longue.

et ya pas à sortir de là,

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.

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.

même si tu en arrive aux insultes à cause de ton manque de culture.

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.

Je sais être déplacé et incivil, moi aussi.

Donc bon, mytho c'est çui qui le dit qui l'est, faut lire un peu autre chose que des manuels d'informatique.

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.

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.

[gl]

( = l'algo décrit en le moins de mot est le plus simple)

C'est là que mon avis (et visiblement je ne suis pas le seul) diffère du tien.

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).

[JoeChip]

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.

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.

Arf.

[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.