Citation :Donc, vérifier avant d'insérer est idiot, c'est juste une perte de temps et de puissance mue par la volonté de faire un code bullet-proof.Oui, c'est idiot si c'est déjà fait par le SQL, on est d'accord
Ce qui me gène, c'est que les "bornes" de validité d'une fonction sont exagérées dans les docs et il me semble que c'st cela qui rend les codes long à débuger.
La preuve amène un débugage rapide: si la fonction prouvée foire, alors c'est qu'une des hypothèses de base foire (par exemple, l'hypothèse "le hardware est 100% fiable" ou "le SQL gère l'insertion d'une clef déjà existante"). Cela évite d'aller chercher dans le code d'où vient l'erreur: on sait qu'elle vient d'une des hypothèses.
Pour appendChild, faute de doc, je ne savais pas sa réaction, d'où la nécessité de ces lignes de "if". Mais oui, je pense que le problème porte aussi sur l'aspect non formel des documentations.
D'accord pour cet autre aspect du test. On teste plus l'expérience utilisateur de son code que le code lui même dans ce cas, c'est cela?
A mon sens, oui, si je devais classer du moins bon au meilleur, je dirai:
- Ne pas tester (ne pas savoir si le projet marche)
- Tester à la main (débug long)
- Prouver à la main (perdre du temps)
- Tester automatiquement (rapide et plutôt efficace)
- Prouver automatiquement (rapide et efficace)
Bon, ben "y'a plus qu'à" faire l'outil de preuve automatique :p
Ou mettre en place un système de typage "hyper fort": si la fonction prend "Integer" en entrée, elle doit faire ce qui est dit dans la doc, pour TOUT integer et si cela ne marche que pour les positifs stricts, changer de typage pour PositiveInteger.