Opérateur logique ou opérateur ternaire ?

**fredoche** · 17/04/2018, 15h51

Bonjour

Je suis à la recherche d'opinions, ou éventuellement d'une discussion autour d'un choix qui n'est pas forcément cornélien, et que je ne sais pas trop arbitrer avec mes connaissances actuelles.

exemple concret :
fonction évaluant la taille d'un fichier si c'est bien un fichier et si une taille minimum est fournie.

Avec des opérateurs logiques

Code :

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

1
2
3
4
 
function searchSize(){
                 return minfilesize && isFile && fsObj.Size>=minfilesize;
             }

Avec des opérateurs ternaires :

Code :

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

1
2
3
4
5
6
7
 
function searchSize(){
                 return minfilesize ?
                    isFile ? fsObj.Size>=minfilesize
                    :false
                :false;
             }

Je ne crois pas voir de différences fondamentales en terme de performance avec mes échantillons actuels sur ces 2 formes d'expression. Les résultats retournés sont les mêmes bien sur.

Avec des opérateurs logiques je sais qu'il y a une évaluation en court-circuit, qui peut peut-être s'avérer plus rapide (???)

La seconde me parait plus facile à lire, plus "langage naturel" mais c'est peut-être personnel. Ces opérateurs ternaires ne sont pas toujours compris par tous.

**danielhagnoul** · 17/04/2018, 19h30

Moi je ne comprends pas vos codes !

L'opérateur ternaire, c'est si ( ) alors () sinon ( ) : exemple : ( n > 4 ) ? ( n ) : ( 4 )
C'est un if ( ){ ... } else { ... } simplifié.

**fredoche** · 17/04/2018, 20h13

non c'est vraiment une expression en soi, pas seulement un if simplifié

enfin je ne suis pas assez pointu pour défendre ce genre de choses correctement mais après avoir lu cet article récemment, j'ai essayé et je m'y suis mis avec un certain plaisir :
https://medium.com/javascript-scene/...t-361bddd0f340

notamment pour le coté programmation fonctionnelle, l'absence d'effet de bords ou de mutation

j'ai écrit d'autres trucs dans le même style, je suis même pas loin d'en abuser :

Code :

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

1
2
3
4
5
6
7
8
9
 
function searchDate(){
                 return isFile ? 
                    startDate ? 
                        endDate ? dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) && dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
                        : dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) 
                    : endDate ? dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate):false
                :false;
             }

Vu que tout est utilisé pour retourner du booléen en fin de compte, ça me plait pas mal

Mais si je comprends bien tu ne choisirais ni la 1ère ni la 2e

**danielhagnoul** · 17/04/2018, 20h17

Bien entendu l'opérateur ternaire est un opérateur JS !
Bien entendu comparaison n'est pas raison !

**fredoche** · 17/04/2018, 21h12

Bon c'est pas grave hein... j'ai bien vu dans les commentaires de l'article que ça ne faisait pas l'unanimité, loin de là

petite remarque sur ton nota bene :

Nota bene : si vous devez être compatible avec les navigateurs obsolètes (IE8 et plus), vous devez convertir les codes ES2015 en ES5 avec Babel.

Vu que je connais bien ce problème, IE8 c'est plutôt ECMAscript version 3, ou ES3 si on suit cette notation

**grunk** · 18/04/2018, 23h19

Code :

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

return minfilesize && isFile && fsObj.Size>=minfilesize;

Se lit facilement

Ce qui n'est pas le cas de

Code :

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

1
2
3
4
return minfilesize ?
                    isFile ? fsObj.Size>=minfilesize
                    :false
                :false;

Et encore moins de ton second exemple qui relève du masochisme

L'opérateur ternaire n'a pour moi d'intérêt que dans toute petite comparaison où écrire un if/else est "lourd" par rapport à la comparaison.

Y'a certaine team qui banisse l'opérateur ternaire , justement parce que certains sont un peu dérangé et écrivent des truc illisibles

Mais ça va sans doute de paire avec la programation fonctionelle , à chaque fois que j'en vois je trouve ça compliqué à lire.

**Marco46** · 19/04/2018, 10h16

C'est facile à lire si c'est bien indenté. Là désolé fredoche mais c'est illisible sur chaque exemple que tu donnes simplement à cause de ça.

**Loralina** · 19/04/2018, 11h34

Bonjour,

Envoyé par fredoche

Les résultats retournés sont les mêmes bien sur.

Pas toujours :

Code :

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

1
2
3
var minfilesize=0, isFile=true, fsObj={Size:10};
console.log(minfilesize && isFile && fsObj.Size>=minfilesize); //0
console.log(minfilesize ? isFile ? fsObj.Size>=minfilesize : false : false); //false

De plus, on pourrait s'attendre à avoir true (à moins de considérer 0 comme signifiant que la taille minimum n'est pas fournie).
C'est un peu ce qui arrive quand on fait ce genre de tests minfilesize ?, startDate ? (quand on lit ça, on se demande ce qu'est "startDate", une chaîne, un nombre, un objet...).
Ma préférence personnelle est de faire des comparaisons claires et nettes et en strict.
Le code est un peu plus long, mais plus lisible, on voit tout de suite le type de la variable (ou d'un retour de fonction), pas simplement en lisant le nom de la variable, et puis surtout on évite de mauvaises surprises.

**NoSmoking** · 19/04/2018, 14h22

Bonjour,

Envoyé par Marco46

C'est facile à lire si c'est bien indenté.

comment dans ce cas écrirais tu indentes le bout de code de fredoche ?

Code :

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

1
2
3
4
5
6
7
8
function searchDate(){
                 return isFile ? 
                    startDate ? 
                        endDate ? dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) && dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
                        : dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) 
                    : endDate ? dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate):false
                :false;
             }

Je suis un peu comme Loralina, il faut que cela soit claire et net, donc cela reste souvent au premier niveau et en ligne. J'aime bien d'un coup d'oeil voir de quoi on parle !

**fredoche** · 19/04/2018, 15h31

Merci pour tous vos retours

Envoyé par grunk

Y'a certaine team qui banisse l'opérateur ternaire , justement parce que certains sont un peu dérangé et écrivent des truc illisibles

Mais ça va sans doute de paire avec la programation fonctionelle , à chaque fois que j'en vois je trouve ça compliqué à lire.

Bon à savoir quand même
A te lire, je me demande si le coté codeur solitaire ne joue pas. Pas le souci de relire le code des autres, et pas trop d'être relu
M'enfin la première syntaxe ne te déplait pas

Envoyé par Marco46

C'est facile à lire si c'est bien indenté. Là désolé fredoche mais c'est illisible sur chaque exemple que tu donnes simplement à cause de ça.

Oui alors je suis entièrement d'accord mais je ne vois pas comment l'indenter pour le rendre plus lisible. J'ai cherché un peu sans vraiment voir quelque chose de parlant. Si tu as des exemples, je suis preneur.

Envoyé par Loralina

Bonjour,

Pas toujours :

Code :

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

1
2
3
var minfilesize=0, isFile=true, fsObj={Size:10};
console.log(minfilesize && isFile && fsObj.Size>=minfilesize); //0
console.log(minfilesize ? isFile ? fsObj.Size>=minfilesize : false : false); //false

De plus, on pourrait s'attendre à avoir true (à moins de considérer 0 comme signifiant que la taille minimum n'est pas fournie).
C'est un peu ce qui arrive quand on fait ce genre de tests minfilesize ?, startDate ? (quand on lit ça, on se demande ce qu'est "startDate", une chaîne, un nombre, un objet...).
Ma préférence personnelle est de faire des comparaisons claires et nettes et en strict.
Le code est un peu plus long, mais plus lisible, on voit tout de suite le type de la variable (ou d'un retour de fonction), pas simplement en lisant le nom de la variable, et puis surtout on évite de mauvaises surprises.

Merci ce retour

A vrai dire, quelque part je joue avec le typage dynamique de javascript, plutôt que de forcer des types. De même avec les booléens et une valeur comme 0 est considérée comme fausse
Ce qui m'intéresse à la sortie de tous ces tests, c'est un vrai/faux
en fait minfilesize est le résultat de cette fonction :

Code :

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

1
2
3
function formatFileSize(size){
           return size>0 && size*1024*1024;
        }

C'est un peu ce qui arrive quand on fait ce genre de tests minfilesize ?, startDate ? (quand on lit ça, on se demande ce qu'est "startDate", une chaîne, un nombre, un objet...).

hé bien c'est soit une valeur déjà formatée et on la traite puisqu'elle vaut true du point de vue du langage, soit elle vaut false. Donc... hummm... soit un nombre pour minfilesize, soit un objet Date, soit un booléen false si le formatage ne donne rien.

En fait, c'est un peu le cœur du problème. Est ce que je profite de ce typage dynamique qui est offert avec le langage ? Pour ce genre d'expression ça me semble marcher pas mal. Je ne me rends pas bien compte où ça peut me mener, où ça pourrait être dangereux.

Donc là genre truc énorme je prends la valeur saisie qui est un string puisque issu d'un paramètre de requête, je laisse javascript le transformer pour le comparer à 0, et ma foi j'utilise son résultat, false ou une valeur en octets.
C'est bête de faire comme ça ?

**Loralina** · 19/04/2018, 23h45

Bonsoir,

Envoyé par fredoche

Je ne me rends pas bien compte où ça peut me mener, où ça pourrait être dangereux.

Si tout est maîtrisé de bout en bout, alors ça fonctionnera évidemment (mais quand vous relirez ultérieurement le code, tout ne sera pas forcément très clair).
Le danger, c'est si on ne fait pas attention, exemple :

Code :

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

1
2
3
var laCombinaisonEstBonne="0"; //ce peut être la valeur d'un champ, d'un retour ajax...
if(laCombinaisonEstBonne) {console.log("Ouvrez le coffre-fort !");} //ça passe
if(laCombinaisonEstBonne===true) {console.log("Ouvrez le coffre-fort !");} //ça ne passe pas

Maintenant, si le programme ne gère à coup sûr que des entiers 0 ou 1, par exemple, alors il n'y aura pas de problème.

Il n'empêche que if(laCombinaisonEstBonne) n'a pas vraiment l'allure d'une condition robuste, elle laisse potentiellement passer trop de valeurs.

Ca me fait l'effet de : "est-ce que ça a l'air bon ?".
Alors que if(laCombinaisonEstBonne===true) pose la question "est-ce que c'est bon ?".

Invité · 20/04/2018, 08h12

Bonjour,

... je me demande si le coté codeur solitaire ne joue pas. Pas le souci de relire le code des autres, et pas trop d'être relu...

À mon avis, le noeud du problème est là.
La question n'est pas "la syntaxe" du code, mais sa "reprise" éventuelle (par un autre, ou même par toi dans quelques mois/années).

Qu'il soit "lisible" est une chose, qu'il soit "compréhensible" en est une autre.

Peut-être que des commentaires (explication du code) suffiraient alors.

**Marco46** · 20/04/2018, 15h28

Ouai alors en fait j'avais pas pigé la structure du bout de code fredoche, justement parce que l'indentation était pas top. Si on prend la manière dont Eric Elliott indente ça donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
function searchDate() {
    return isFile
        ? startDate
        ? endDate
        ? dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) && dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
        : dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate)
        : endDate
        ? dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
        : false
        : false;
}

Et là j'avoue c'est chaud.

C'est peut être plus lisible de cette manière :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
function searchDate() {
    return isFile
        ? startDate
            ? endDate
                ? dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate) && dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
                : dateUtil.dateFns.isAfter(fsObj.DateLastModified, startDate)
            : endDate
                ? dateUtil.dateFns.isBefore(fsObj.DateLastModified, endDate)
                : false
        : false;
}