Bonjour,
Un exemple vaut mieux qu'un long discours.
Par convention, écrivez-vous
ouCode:if (maFonction()) { ... }
Et pourquoi ?Code:if (maFonction() == TRUE) { ... }
Version imprimable
Bonjour,
Un exemple vaut mieux qu'un long discours.
Par convention, écrivez-vous
ouCode:if (maFonction()) { ... }
Et pourquoi ?Code:if (maFonction() == TRUE) { ... }
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é :
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).Code:
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 { }
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.
Ne pas mettre un commentaire à jour, c'est un bug.Citation:
Envoyé par IDontLikeYou
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 ?Citation:
Envoyé par IDontLikeYou
Code:
2if (ma_var) {
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 :Code:
2if (ma_var == 1) {
- é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...Citation:
Envoyé par gangsoleil
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...Citation:
Envoyé par gangsoleil
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
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 ?"Code:if je_dois_le_faire() then je_le_fais() else je_fais_autre_chose()
Il y a quand même bien peu d'intérêt...
8O 8O Mais quelle horreur et quelle flemmardise !!!!!! :roll: :roll:
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
N'EST PAS EQUIVALENT àCode:if ( x )
Code: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
que de lireCode:if ( toto == False )
Code: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.....
:calim2:
Eh bien ce sont des outils stupides.. :PCitation:
Envoyé par IDontLikeYou
Voir plus haut...
Ah oui ???Citation:
Envoyé par IDontLikeYou
Alors tu t'interdis d'écrire ;
où toto est une fonction renvoyant un entier...Code:if ( toto() )
:P:P
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...Citation:
Envoyé par souviron34
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 ==...
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.Citation:
Envoyé par souviron34
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.
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 parCitation:
Envoyé par souviron34
Tu as rajouté 4 caractères, et levé toute ambiguité. Hop.Code:if (toto () <> 0)
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...Citation:
Envoyé par souviron34
Bonjour,
Un compilateur bien réglé te préviens de ce genre d'erreur. Ensuite, si tu les laisses passer, c'est ton problème.Citation:
Envoyé par IDontLikeYou
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.Citation:
Envoyé par TropMDR
Desole, c'est vrai que ce que j'ai ecrit n'etait pas clair du tout.
oh! la! on se calme!
Nous sommes entre gentlemen, pas besoin de se bouffer le nez pour si peu.....
pour répondre à IdontLikeYou, qui disaitça, c'est pour des gens qui n'ont jamais fait de maintenance. Pour moi(ça n'est que mon avis, hein), le code seul doit être parfaitement compréhensible sans les commentaires, mais aussi vice versa : les commentaires seuls doivent permettre de comprendre le code.Citation:
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...
Pourquoi?
Parceque quand on recherche un peu au hasard dans des dizaines de milliers de lignes de code, on ne va pas s'amuser à tout comprendre. Quand j'ai un commentaire qui dit "algorithme de determination du type d'avis d'échéance en fonction du type de paiement et du montant. Les paiements par TIP font un avis TIP sauf si le montant dépasse 1 million d'euros, les paiements virements font toujours un avis virement, et les autres sont répartis entre édition en central et édition à l'agence. Les TIP de plus de 1 million sont édités en central", eh bien je n'ai pas à me taper les 20/30 lignes de code, qui, même bien écrites, seront quand même bien plus longues à analyser.
Et comme ça n'autorise pas à écrire comme un goret, les 20 lignes en question doivent, effectivement, être parfaitement lisible sans commentaires. Mais j'insiste, pour avoir eu à gérer le cas ci-dessus et plein d'autres, dans des programmes hyper vieux, les 2 sont indispensables : un code lisible sans commentaires, et un commentaires compréhensible sans avoir à se farcir le code.
Pour ce qui est de la question initiale, ça dépend du langage. En VBA, j'ai tendance à mettre la version longue(mais pas toujours, et c'est sans doute mal). En Cobol, le FALSE n'est pas d'usage facile, et on préfère s'en passer. Exemple :
On voit ici que le booléen peut prendre n'importe quelle valeur en COBOL - j'ai volontairement mis des valeurs exotiques, même si en général je met '0' et '1'.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1801 BOOLEEN-FIN-FICHIER PIC X. 88 FIN-FICHIER-OUI VALUE '5'. 88 FIN-FICHIER-NON VALUE '9'. (.../...) READ NOMFICH AT END SET FIN-FICHIER-OUI TO TRUE NOT AT END SET FIN-FICHIER-NON TO TRUE END-READ (.../...) IF FIN-FICHIER-OUI PERFORM TRAITEMENT-FIN END-IF IF FIN-FICHIER-NON PERFORM TRAITEMENT-ENREG-LU END-IF (.../...)
FALSE n'a donc pas de sens dans ce contexte. Et puisqu'un ne peut pas assigner ou tester FALSE (le SET MACHIN = FALSE ne signifie rien, le compilateur ne saurait pas quelle valeur mettre) , tester TRUE n'aurait pas plus de sens - c'est la seule valeur possible. Donc on s'en passe. En fait, c'est quasiment le nom du booleen qui permet de savoir si on est en FALSE ou en TRUE.
J'ajouterais que le cerveau humain a tendance à mieux gérer les informations positives.
c'est quand même largement moins lisible.....Code:
2
3
4
5
6IF NOT FIN-FICHIER-NON PERFORM TRAITEMENT-FIN END-IF IF NOT FIN-FICHIER-OUI PERFORM TRAITEMENT-ENREG-LU END-IF
Alors ça va mieux en le disant :DCitation:
Envoyé par IDontLikeYou
Parce que la question est générale, et nul part dans ton message ça n'apparaît...
Qu'il y ait des débats, certes..Citation:
Envoyé par IDontLikeYou
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...
Je n'ai pas parlé des commentaires...Citation:
Envoyé par IDontLikeYou
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:
2
3
Oh si, bien que vraiment de très loin en très loin (du genre 1 fois tous les 3 ou 4 ans)...Citation:
Envoyé par IDontLikeYou
Mais ton compilo te le dit instantanémanent (-Wall) :P
Donc franchement pas un problème...
Et donc pas une raison pour rendre un code "ambigu" ...
tu as mal lu... :aie:Citation:
Envoyé par TropMDR
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...
C'est bien ce que je dis...Citation:
Envoyé par TropMDR
Je ne vois qu'une raison : la flemme, pour ne pas écrire un test long...
D'accord avec tout le reste, mais ça, pas toujours. En C, peut-être. En VBA(que je pratique), aussi. En COBOL, non, parceque la comparaison implicite est bien plus lisible et maintenable.Citation:
Envoyé par souviron34
La réponse dépend évidemment du type de langage utilisé. la notation "!monBooleen" est extrêmement illisible, je suis bien d'accord. Mais quand on arrive à des langages naturellement verbeux(genre VBA), on a "not monBooleen" qui est déjà plus lisible. Je suis d'accord que "monBooleen = false" (ou == suivant le langage) est encore plus lisible, mais le gain est moindre. Mais en cobol, comme on est obligé de définir les labels booléens du genre MON-BOOLEEN-TRUE et MON-BOOLEEN-FALSE, on ne va pas commencer à mettre des "IF MON-BOOLEEN-FALSE = TRUE"
C'est lourd, redondant, et illisible. Autant rajouter de l'explicite sur un langage concis comme le C/C++ me parait utile, autant sur un langage déjà naturellement verbeux, ça peut assez vite ajouter de la lourdeur et de la confusion.
Après, la question initiale semblait porter sur un langage concis, donc sur ce point-là, je suis d'accord avec toi. Mais ça n'est pas un absolu.