Si tu prend un ensemble de x criteres, alors l'ensemble des parties de cet ensemble de x criteres est de 2^x criteres.
Appliqué à la programmation cela donne, il faut surtout reduire le nombre de "if", leur imbrication et augmenter leur lisibilité.
bien souvent l'essentiel des bugs sont sur des effet de bord dans des conditions mal traitée ou pas traitées du tout. dans la liste on trouve :
- mauvaise gestion du malloc()/free()
- mauvaise gestion des IPC
- explosion d'etat interdependant car le code ne permet de faire autrement dans le delai imparti ( car sinon faut tout recoder )
si on regarde bien, il n'y a là dedans que des erreurs de conceptions ou d'implementation. ce qui m'amene a une regle que j'enonce ainsi :
- tout programme ou bout de programme dont la couverture en condition est superieur à 5 tends necessairement à être buggé
si tu as un doute, reprends le propos de dijkstra sur les goto. il dit les goto sont a eviter. soit, il a raison la dessus. par contre, si l'on deroule le code de tel maniere qu'il n'y ait plus de goto inconditionnel, il ne pourra rester au plus qu'un seul : celui d'une boucle infini. tous les autres goto sont sujet à des conditions prealable permettant soit de faire le goto soit de passer a l'instruction suivante.
Aujourd'hui, il faut necessairement comprendre le propos de Dijkstra comme les conditions prealable au goto sont a eviter.
[^] # Re: pas clair ...
Posté par Mouns . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 3.
Si tu prend un ensemble de x criteres, alors l'ensemble des parties de cet ensemble de x criteres est de 2^x criteres.
Appliqué à la programmation cela donne, il faut surtout reduire le nombre de "if", leur imbrication et augmenter leur lisibilité.
bien souvent l'essentiel des bugs sont sur des effet de bord dans des conditions mal traitée ou pas traitées du tout. dans la liste on trouve :
- mauvaise gestion du malloc()/free()
- mauvaise gestion des IPC
- explosion d'etat interdependant car le code ne permet de faire autrement dans le delai imparti ( car sinon faut tout recoder )
si on regarde bien, il n'y a là dedans que des erreurs de conceptions ou d'implementation. ce qui m'amene a une regle que j'enonce ainsi :
- tout programme ou bout de programme dont la couverture en condition est superieur à 5 tends necessairement à être buggé
si tu as un doute, reprends le propos de dijkstra sur les goto. il dit les goto sont a eviter. soit, il a raison la dessus. par contre, si l'on deroule le code de tel maniere qu'il n'y ait plus de goto inconditionnel, il ne pourra rester au plus qu'un seul : celui d'une boucle infini. tous les autres goto sont sujet à des conditions prealable permettant soit de faire le goto soit de passer a l'instruction suivante.
Aujourd'hui, il faut necessairement comprendre le propos de Dijkstra comme les conditions prealable au goto sont a eviter.