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;
}