Discussion :

[dorian53]

Bonjour,

Un exemple vaut mieux qu'un long discours.
Par convention, écrivez-vous

Code :

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

if (maFonction()) { ... }

ou

Code :

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

if (maFonction() == TRUE) { ... }

Et pourquoi ?

[gangsoleil]

Bonjour,

Sauf cas exceptionnel, j'écris toujours du code long, et en plus je le commente. La raison est simple : dans certains cas, les tests courts comme tu les appels deviennent non triviaux.
Si tu as une fonction qui renvoie un booleen, pas de soucis. Mais si tu as une fonction qui s'appelle Dois-je-le-faire(), et qu'elle renvoie 0, est-ce que cela veut dire que tu dois le faire, ou que tu ne dois pas le faire ?

Alors qu'avec le code suivant, pas d'ambiguĩté :

Code :

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

1
2
3
4
5
6
7
8
9
10
/* Si je dois le faire */
if (dois-je-le-faire() == 0)
{

}
/* sinon je ne dois pas le faire
else
{

}

Et ca ne prend pas plus de temps a écrire (ou alors c'est comme pour les gens qui écrivent en langage SMS pour gagner du temps).

[IDontLikeYou]

Hmmm exemple à l'opposé de ce qui est préconisé. Le code parle de lui même, les commentaires sont redondants. De plus, si ce code est modifié par quelqu'un d'autre, il y a 90% de chances pour qu'il ne mette pas les commentaires à jour...

Concernant les tests longs : c'est affaire de goût à mon avis, mais sache que certains outils de mesure de la qualité du code font la chasse aux tests longs en considérant qu'ils sont redondants.

[gangsoleil]

Hmmm exemple à l'opposé de ce qui est préconisé. Le code parle de lui même, les commentaires sont redondants. De plus, si ce code est modifié par quelqu'un d'autre, il y a 90% de chances pour qu'il ne mette pas les commentaires à jour...

Ne pas mettre un commentaire à jour, c'est un bug.
Tu peux aussi considérer qu'il ne mettra à jour que la moitié du code, et que donc il ne faut pas faire de else...

Concernant les tests longs : c'est affaire de goût à mon avis, mais sache que certains outils de mesure de la qualité du code font la chasse aux tests longs en considérant qu'ils sont redondants.

Et ces mêmes outils considèrent-ils que de ces deux codes, le premier est meilleur ?

Code :

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

1
2
if (ma_var)
{

Code :

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

1
2
if (ma_var == 1)
{

Si oui, tu as un soucis, car ces deux codes sont différents. Donc si j'ai besoin du second, j'ai le choix entre :

• écrire du code juste, mais "non propre" pour ces outlis
• écrire du code faux, mais "propre" au sens de ces outils

C'est vrai qu'entre les eux....

[IDontLikeYou]

Ne pas mettre un commentaire à jour, c'est un bug.
Tu peux aussi considérer qu'il ne mettra à jour que la moitié du code, et que donc il ne faut pas faire de else...


Et ces mêmes outils considèrent-ils que de ces deux codes, le premier est meilleur ?

Code :

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

1
2
if (ma_var)
{

Code :

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

1
2
if (ma_var == 1)
{

Si oui, tu as un soucis, car ces deux codes sont différents. Donc si j'ai besoin du second, j'ai le choix entre :

• écrire du code juste, mais "non propre" pour ces outlis
• écrire du code faux, mais "propre" au sens de ces outils

C'est vrai qu'entre les eux....

Désolé j'utilise un langage "plus propre" qui fait la distinction entre booléens et entiers...

[TropMDR]

Si tu as une fonction qui renvoie un booleen, pas de soucis. Mais si tu as une fonction qui s'appelle Dois-je-le-faire(), et qu'elle renvoie 0, est-ce que cela veut dire que tu dois le faire, ou que tu ne dois pas le faire ?

Si tu as une fonction qui s'appelle "dois_je_le_faire" et qui répond false pour dire oui, c'est qu'il est grand temps de la changer (et de brûler son auteur). Si tu ne peux pas la changer, au moins la wrapper dans une fonction qui répond dans le bon sens...

Ensuite, en français, je me dirais "si je dois le faire, alors je le fait, sinon je fais autre chose. Donc autant que le code y ressemble le plus possible

Code :

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

if je_dois_le_faire() then je_le_fais() else je_fais_autre_chose()

mettre un "je_dois_le_faire() = true" en plus, ça alourdis juste le code, et ça fait que le relecteur se demande "mais pourquoi un test en plus ?"

Il y a quand même bien peu d'intérêt...

[souviron34]

Mais quelle horreur et quelle flemmardise !!!!!!


Arrêtez-vous seulement un instant sur ceux qui reprendront votre code éventuellement dans 10 ou 20 ans, et qui auront été formés sur un autre langage....


D'une part, même aujourd'hui, la définition de True ou False n'est pas équivalente à 0 ou 1....

Comme cela dépend de "define", rien n'empêche (et c'est d'ailleurs le cas sur un certain nombre de systèmes ou dans un certains langages) de définir True comme 0 et False comme 1... Ou comme tout ce qui n'est pas 0.. Ou réciproquement...

Donc

Code :

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

if ( x )

N'EST PAS EQUIVALENT à

Code :

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

if ( x == True )

Mais avec un "booléen" c'est une chose relativement facile... Si maintenant, ce qu'on voit de plus en plus malheureusement, on se sert de ce genre de raccourcis pour tester des pointeurs, des entiers, etc etc, c'est ARCHI-FAUX et DANGEREUX ...


C'est uniquement pas CONVENTION que, la plupart du temps, NULL est défini comme 0x0...

Mais, vu que la définition de True peut être 0, et que le type est un pointeur, tout dépend alors de la troncation et/ou cast...


Enfin, il est très nettement plus clair pour le lecteur de voir

Code :

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

if ( toto == False )

que de lire

Code :

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

if ( ! toto )

Et si c'est vrai pour le False, c'est AUSSI vrai pour le True....



Et "économiser" 6 touches de clavier rendra le code beaucoup moins clair et lisible (et transformable automatiquement : un outil qui transformerai d'un langage dans un autre aurait bien du mal à évaluer une fonction qui n'est pas du type attendu...)


Vraiment navrant comme attitude.....

Concernant les tests longs : c'est affaire de goût à mon avis, mais sache que certains outils de mesure de la qualité du code font la chasse aux tests longs en considérant qu'ils sont redondants.

Eh bien ce sont des outils stupides..

Voir plus haut...

Désolé j'utilise un langage "plus propre" qui fait la distinction entre booléens et entiers...

Ah oui ???

Alors tu t'interdis d'écrire ;

Code :

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

if ( toto() )

où toto est une fonction renvoyant un entier...



Et si jamais tu changes de langage ??

Parce que, dans notre métier, ça arrive tous les jours ou quasiment...

[IDontLikeYou]

Eh bien ce sont des outils stupides..

Voir plus haut...




Ah oui ???

Alors tu t'interdis d'écrire ;

Code :

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

if ( toto() )

où toto est une fonction renvoyant un entier...



Et si jamais tu changes de langage ??

Parce que, dans notre métier, ça arrive tous les jours ou quasiment...

Je passe sur toute la partie ayant rapport au C/C++... Ma réponse était liée à des langages type java où le typage booléen est fort. Dans le cadre de ce langage, certains outils font la chasse au test long, je ne sais pas quel est le rationnel derrière, mais c'était juste pour signaler que ça existait...

Maintenant il me semblait qu'aujourd'hui en développement il y avait un consensus autour de l'inutilité, voire la dangerosité de la redondance, il semblerait que je me trompe.

Si votre code ne dit pas ce qu'il fait et que vous vous sentez obligés d'ajouter des commentaires, pensez à changer votre code d'abord.

PS : surtout qu'en C/C++ vous allez me certifier que vous n'avez jamais rencontré de bug de la forme if (variable = valeur) au lieu du ==...

[gangsoleil]

Bonjour,

PS : surtout qu'en C/C++ vous allez me certifier que vous n'avez jamais rencontré de bug de la forme if (variable = valeur) au lieu du ==...

Un compilateur bien réglé te préviens de ce genre d'erreur. Ensuite, si tu les laisses passer, c'est ton problème.

[TropMDR]

D'une part, même aujourd'hui, la définition de True ou False n'est pas équivalente à 0 ou 1....

Comme cela dépend de "define", rien n'empêche (et c'est d'ailleurs le cas sur un certain nombre de systèmes ou dans un certains langages) de définir True comme 0 et False comme 1... Ou comme tout ce qui n'est pas 0.. Ou réciproquement...

Donc

Code :

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

if ( x )

N'EST PAS EQUIVALENT à

Code :

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

if ( x == True )

[...]
Enfin, il est très nettement plus clair pour le lecteur de voir

Code :

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

if ( toto == False )

que de lire

Code :

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

if ( ! toto )

Moi je ne comprends rien là. Tu nous dis "pour tester si une valeur "booleenne" est vrai, il ne faut pas la comparer à TRUE, parce que dans certain langage (genre C), la convention est que n'importe quel entier positif est vrai". La je suis d'accord.

Ensuite, tu nous dit "les définitions de vrai et faux sont interchangeable suivant les langages". Bon, soit

Puis tu nous dit que pour tester si un booleen est faux, il FAUT le comparer à FALSE.

Euh, what the fuck? Genre en 10 lignes, tu as dit une chose et son contraire absolu.

Ah oui ???

Alors tu t'interdis d'écrire ;

Code :

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

if ( toto() )

où toto est une fonction renvoyant un entier...

Euh, bah, oui en fait. Tout simplement parce que un entier n'est pas un booleen et vice versa. Pour reprendre ce que tu disais au dessus, le lien booléen <-> entier est arbitraire. Donc suivant le choix, ton test fera tout et son contraire... donc il suffit de remplacer par

Code :

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

if (toto () <> 0)

Tu as rajouté 4 caractères, et levé toute ambiguité. Hop.

Et si jamais tu changes de langage ??

Parce que, dans notre métier, ça arrive tous les jours ou quasiment...

En même temps, si tu t'imposes d'écrire ton code uniquement dans l'intersection de tous les langages possibles, tu ne vas pas aller loin...

[gangsoleil]

Moi je ne comprends rien là. Tu nous dis "pour tester si une valeur "booleenne" est vrai, il ne faut pas la comparer à TRUE, parce que dans certain langage (genre C), la convention est que n'importe quel entier positif est vrai". La je suis d'accord.

Ensuite, tu nous dit "les définitions de vrai et faux sont interchangeable suivant les langages". Bon, soit

Puis tu nous dit que pour tester si un booleen est faux, il FAUT le comparer à FALSE.

Euh, what the fuck? Genre en 10 lignes, tu as dit une chose et son contraire absolu.

Nous sommes bien d'accord : chaque cas est différent, et c'est le bordel. Je voulais juste montrer que c'est le bordel, et qu'écrire 5 ou 6 caractères de plus pour lever toute ambiguïté, ça permet de résoudre les problèmes.
Desole, c'est vrai que ce que j'ai ecrit n'etait pas clair du tout.

[souviron34]

Ma réponse était liée à des langages type java où le typage booléen est fort.

Alors ça va mieux en le disant

Parce que la question est générale, et nul part dans ton message ça n'apparaît...

Maintenant il me semblait qu'aujourd'hui en développement il y avait un consensus autour de l'inutilité, voire la dangerosité de la redondance, il semblerait que je me trompe.

Qu'il y ait des débats, certes..

Un consensus je crois qu'on en est loin...

Le "consensus" de toutes les personnes ayant travaillé depuis de longus années est que les commentaires c'est bien....

Même si ils ne sont pas toujours à jour, c'est certainement mieux que d'avoir à déchiffrer du code en permanence.... pour comprendre la structure d'un prog ou ce que fait telle ou telle variable ou test...

Si votre code ne dit pas ce qu'il fait et que vous vous sentez obligés d'ajouter des commentaires, pensez à changer votre code d'abord.

Je n'ai pas parlé des commentaires...

Disons que l'exemple cité par gangsoleil n'est pas des plus parlants..

Mais si le nom de la variable (ou de la fonction) n'est pas aussi évident, il est toujours intéressant de dire ce que ça fait réellement...

du style

Code :

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

1
2
3
/* le seuil minimal est le seuil de décrochage de l'avion */
if ( vitesse < seuil )
   fait-ceci

PS : surtout qu'en C/C++ vous allez me certifier que vous n'avez jamais rencontré de bug de la forme if (variable = valeur) au lieu du ==...

Oh si, bien que vraiment de très loin en très loin (du genre 1 fois tous les 3 ou 4 ans)...

Mais ton compilo te le dit instantanémanent (-Wall)

Donc franchement pas un problème...

Et donc pas une raison pour rendre un code "ambigu" ...

Moi je ne comprends rien là. Tu nous dis "pour tester si une valeur "booleenne" est vrai, il ne faut pas la comparer à TRUE, parce que dans certain langage (genre C), la convention est que n'importe quel entier positif est vrai". La je suis d'accord.

Ensuite, tu nous dit "les définitions de vrai et faux sont interchangeable suivant les langages". Bon, soit

Puis tu nous dit que pour tester si un booleen est faux, il FAUT le comparer à FALSE.

Euh, what the fuck? Genre en 10 lignes, tu as dit une chose et son contraire absolu.

tu as mal lu...


je dis au contraire qu'on doit toujours comparer avec la valeur avec laquelle on est censé comparer.... et ne JAMAIS utiliser de tests implicites...

Tu as rajouté 4 caractères, et levé toute ambiguité. Hop.

C'est bien ce que je dis...




Je ne vois qu'une raison : la flemme, pour ne pas écrire un test long...