Discussion :

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

[thelvin]

Bah c'est insoluble, pour moi la perception de l'intention est immédiate pour B : on regarde si s est égal à "abcd".

Et comme je l'ai dit au tout début, cette perception est parfaitement acceptable, et tout à fait légitime. Mais cette perception, c'est toi qui la fait, c'est à toi qu'elle s'applique. Ce n'est pas un fait. Ce n'est pas objectif.

Il y a des gens pour qui c'est tout à fait immédiat et d'autres pour qui ça ne l'est pas assez pour que ce soit considéré équivalent. Et rien d'objectif, rien qui marche, ne peut leur être opposé, ce qui signifie au fond qu'aucun des deux n'a plus tort ou raison que l'autre.
C'est comme ça. Ça peut ne pas nous arranger, on peut ne pas aimer ça, mais la vie n'est pas juste, parfois la réalité n'est pas ce qu'on veut qu'elle soit.

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

Le fait même que tu te poses cette question indique qu'elle a dû être posée. Une notation fait en sorte que la question ne se pose pas, l'autre on sait que ça marche si on fait l'effort de se poser la question.

Pour le dire autrement, c'est un niveau d'indirection de réflexion supplémentaire.
Pour le dire encore autrement, c'est moins explicite.

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

Sans importance par rapport à ce que j'ai dit au-dessus.

Mais j'ai quand même quelque chose à répondre. L'argument que je vais donner est faible, mais pas vraiment faux. Alors je le dis quand même.

Les différences avec le langage naturel ne sont pas "bonnes" en soi. Ce qui est bon c'est d'en éviter les lourdeurs et l'indéterminisme. En gros d'avoir un langage dont le sens sémantique est entièrement défini, et suffisamment peu verbeux pour être utile, et pratique. Le reste on s'en tape.

Mais avec le langage naturel viennent des "manières de penser," de présenter les choses. Certaines manières de dire les choses se lisent avec fluidité et naturellement, et d'autres, un peu moins.
En l'occurrence, personne dans les langues occidentales, ne s'habitue à raisonner, "Si c'est Renault qui est la marque de ta voiture, alors va chez Renault assistance." Mais "Si ta voiture est une Renault, alors va chez Renault assistance." D'abord l'élément variable, ensuite la description constante.
Ce que je veux dire c'est qu'on peut hurler tant qu'on veut que "abcd".equals(variable) se lit de la même manière que variable.equals("abcd"), ça restera toujours aussi faux. Au moins au niveau international et chez nous, le deuxième est un peu plus naturel que l'autre, et infiniment plus courant (notamment le premier ne se fait que pour comparer des pointeurs comparables de cette façon, et jamais en aucune autre occasion (types primitifs et situations où equals ne fait pas la comparaison voulue.))
Et le résultat de tout ça, c'est qu'il y a un peu de perturbation en lisant le premier, au moins jusqu'à s'être formé (et se maintenir) à lire les deux. Je suis même tombé sur un module de checkStyle qui n'aime pas ça. Je ne suis pas d'accord avec ce module, mais il a été créé par quelqu'un de ce monde et a été opposé à du code que j'ai dû défendre. Je le fais souvent contre des imbécilités pures et simples, mais là la seule imbécilité, c'était d'avoir passé du temps à gérer la règle. Pas la règle en elle-même.

Tout ça est vrai. Mais je le trouve faible, parce que :
- la différence n'est pas si grande. Elle n'est significative qu'une fois dans une vie. Les débutants sont précieux, mais on ne fait pas tout en fonction d'eux, et c'est pour de bonnes raisons.
- il y a dans le monde, des cultures qui poussent à penser dans ce sens-là, et je ne considère pas le fait que ça soit très minoritaire, comme un argument. Ça ne le restera pas forcément.

[JoeChip]

Mmh le coup de l'ordre constante/variable est en effet douteux, et il est vrai que j'ai été formé à la "notation polonaise inverse" (très pratique) et que j'ai à une époque joué avec Forth (que je continue à trouver génial). Mais bon, nous n'avons probablement pas la même cible, sémantiquement parlant...

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

[tchize_]

En même temps, si t'amène StringUtils, juste pour faire un equals, c'est de l'overkill

[rg77140]

Hum... qui a dit que j'importais les Commons Apache uniquement pour faire un StringUtils.equals() ? Je pars plutôt du constat que les Commons Apache sont quasiment un standard et qu'il serait bête de s'en passer...

[thelvin]

Justement de nos jours il y a pas mal de compétiteurs avec lesquels Commons-Lang fait double emploi.
Le truc étant que Commons-Lang se concentre, par choix, sur des trucs qui, s'ils servent vraiment à quelque chose, seront proposés aussi par n'importe quelle bibliothèque de soutien.

Mais bon, l'idée est là : en général on a dans le projet une bibliothèque de soutien, et dans ce cas-là, et si on est pas en Java 7, pourquoi pas s'en servir.
(Réponse : parce que le jour où on se débarrasse de cette bibliothèque de soutien qui n'est plus au goût du jour, le projet a soixante milliers de lignes de code à remplacer parce qu'il y a un f*cking Strings.equals(truc, "machin"). Les bibliothèques de soutien ont un côté frustrant quand on doit s'occuper de leur obsolescence.)

[tchize_]

oui enfin, ça prend 10 minutes à remplacer avec un regexp (allez, 20 ^^ )

[thelvin]

Pas faux... Mais même si ça bouffe pas tellement de temps, il faut quand même vérifier que ça a bien fait ce qu'il faut et que ça compile pas par hasard. Ce qui est abominablement répétitif et frustrant.

[tchize_]

Pas faux... Mais même si ça bouffe pas tellement de temps, il faut quand même vérifier que ça a bien fait ce qu'il faut et que ça compile pas par hasard. Ce qui est abominablement répétitif et frustrant.

Bha, comme tout refactoring, tu lance les test unitaires pour vérifier ça, que tu as bien entendu toujours pris soin d'écrire ...

[kremvax]

Bha, comme tout refactoring, tu lance les test unitaires pour vérifier ça, que tu as bien entendu toujours pris soin d'écrire ...

Ahaha aha ah..

[thelvin]

Ça fait quand même beaucoup de branches à tester, là -_-°.

(Et puis oui, en effet, on nous impute que du temps qui ne prend pas le temps nécessaire pour les tests unitaires.)

[tchize_]

Evidement, si tu veux virer ta librairie de toutes tes branches... Quand tu fais une branche par client, ben y a plus qu'a assumer le fait que tu fait maintenance * nombre de clients ^^

Maintenant, tu fais le changement, tu commit, et tu laisse le serveur d'intégration continue lancer tous les tests pendant le w-e, ca te donnera du travail pour la semaine qui vient

[bulbo]

Hum... qui a dit que j'importais les Commons Apache uniquement pour faire un StringUtils.equals() ? Je pars plutôt du constat que les Commons Apache sont quasiment un standard et qu'il serait bête de s'en passer...

Mouais c'est tellement quasiment un standard qu'en 16 ans de carrière je n'ai pas eu un projet qui utilisait vraiment et correctement les commons-lang ou même les commons tout court d'Apache.

Je pense que le soucis c'est que la partie commons-lang fournit des trucs utiles c'est sur, mais tellement basique qu'en fait le programmeur de base les écrit en 2s sans réfléchir.
L'avantage c'est que le prochain programmeur de base les lira et comprendra sans réfléchir non plus. Alors que s'il tombe sur un bout de commons, il va falloir qu'il se plonge dans la javadoc desdit commons pour vérifier la sémantique de l'opération. Le gain, du coup, est plutôt limité. Parce qu'une ligne de code on l'écrit une fois mais combien de fois la relit-on ?

Sans parler de la désagréable habitude qu'ils ont de dépendre les uns des autres.. tu veux faire un client FTP grâce à commons-net .. paf il te faut commons-lang, commons-logging et j'en oublie sûrement.
C'est mignon mais quand une fonctionnalité marginale de mon programme me fait importer 6 fois la taille de mon développement en librairie externe, je me pose sévèrement la question de savoir si ça en vaut le coup.

Surtout qu'on ne sais pas si ladite librairie survivra plus longtemps que mon programme.
Et je ne parle pas des bugs de la librairie qui viendront se rajouter aux miens propres.

Les commons pour moi, tombent très souvent dans la tranche des librairies dont le gain qu'elles apportent se retrouvent largement contrebalancé par ce que ça implique de négatif pour le programme:

- Nouvelle API pas maîtrisée de base par tout le monde (en fait par personne autour de moi aujourd'hui par exemple).
- Bug potentiel de la librairie et donc débuggage compliqué par le fait qu'il va falloir aller fouiner dans le source de la librairie.
- Obsolescence potentielle de la librairie qui obligera finalement soit à coder soi-même tout ce qu'on utilisait, soit, si on n'a pas compris la leçon traduire les appels pour une nouvelle librairie du même type.

Les commons on ça de pervers en plus, que par je ne sais quel procédé marketing, dans la conscience du débutant qui les utilise on a cette vision des choses: commons= code parfait et rapide, API standard = caca.

J'ai vu ici même des gens répondre à une question sur l'utilisation d'un StringTokenizer d'un débutant, qu'il n'avait qu'à lacher le StringTokenizer minable dispo avec le JDK et d'utiliser celui d'apache commons, tellement mieux et performant.
Bon je ne saisi pas bien l'intérêt de re-écrire un StringTokenizer pour faire la même chose que celui du JDK et rien de plus.. mais c'est ça commons.
Ce jour là j'avais également pondu rapidou un StringTokenizer identique en fonctionnalité que celui des commons .. mais plus performant.. comme quoi !

Idem, lorsque qu'Adiguba avait présenté les nouveautés de l'API 1.7 avec notamment l'apparition d'Objects, on avait eu droit à un sale Troll agressif genre "sont con chez Sun de proposer ça alors que ça existe dans commons, donc tout le monde l'utilise déjà et surtout n'utilisez pas Objects, commons fait mieux... puisqu'on vous le dit".

Bref tout ça pour dire que commons .. bah si ça devait être un standard, depuis le temps ça en serait sûrement un. Moi les commons aujourd'hui j'ai un peu l'impression d'une API vieillissante et ça ne me donne guère envie.

Bulbo

[tchize_]

tu veux faire un client FTP grâce à commons-net .. paf il te faut commons-lang, commons-logging et j'en oublie sûrement.

Surement (vive maven).

Blague à part, si t'arrive à coder un client FTP en 2s fait moi signe, je devrais pouvoir essayer de te faire engager

Comme toutes les librairies, faut toujours peser le pour et le contre. Quand tu mais plus de temps à la choisir qu'à écrire toi même la fonctionnalité... Certes. D'ailleurs, tout comme toi, commons-lang et commons-logging, je ne les utilise pas souvent. En fait, que si ils ont déjà été importés pour d'autres raison (et encore, commons logging, c'est du n'importe quoi)

[rg77140]

Je n'ai pas envie de rentrer dans un long débat "commons" ou "pas commons", après tout j'ai pas d'actions chez eux, libre à chacun de les utiliser ou non... Et puis il existe d'autres librairies très biens aussi. La seule chose que je dirai c'est de ne pas réinventer la roue.

Mouais c'est tellement quasiment un standard qu'en 16 ans de carrière je n'ai pas eu un projet qui utilisait vraiment et correctement les commons-lang ou même les commons tout court d'Apache.

En 3 ans j'ai vu beaucoup de projets les utiliser correctement et un projet mal utiliser commons-beans. Comme quoi ça dépend des projets... En même temps utiliser equals, isEmpty, isBlank, isNotBlank, join, filter, ... faut pas être un génie. J'ai aussi vu un projet refuser d'utiliser commons-mail alors que moi je l'ai utilisé. Ils ont eu pleins de bugs sur l'envoi des mails et moi aucun...

Je pense que le soucis c'est que la partie commons-lang fournit des trucs utiles c'est sur, mais tellement basique qu'en fait le programmeur de base les écrit en 2s sans réfléchir.

Soyons sérieux... J'ai déjà vu ce genre de choses. Comme tu dis, en général c'est écrit en 2s, c'est pas testé, c'est crade, c'est pas documenté, ...

Surtout qu'on ne sais pas si ladite librairie survivra plus longtemps que mon programme.

J'ai jamais compris cet argument. Tu télécharges la librairie dans une version. Si la librairie meurt et que tu as besoin d'une fonction qui n'est pas présente dedans, alors je ne vois pas ce qui t'empêche de l'implémenter, tout comme tu l'aurais fait si tu n'avais pas utilisé une librairie de soutien.

Et je ne parle pas des bugs de la librairie qui viendront se rajouter aux miens propres.

J'ai vu beaucoup (mais alors vraiment beaucoup) plus de bugs propres aux projets sur lesquels j'ai bossés que dans les librairies commons, guava ou autre...

Moi les commons aujourd'hui j'ai un peu l'impression d'une API vieillissante et ça ne me donne guère envie

Certaines semblent un peu vieillissantes, c'est vrai. Commons-collection en est plus ou moins un exemple. Mais on peut voir qu'ils sont en train de préparer une v4 qu comble le manque des "generic" au sein de leur librairie. Mais bon il existe d'autres librairies que les commons, je ne les connais pas toutes, mais libre à toi de choisir celle qui te convient le mieux. Si tu n'en trouves aucune, je pense que tu réinventes forcément la roue (à moins que tu utilises une librairie interne à ta société, pourquoi pas).

Romain.