Du code en acier trempé !
Si vous voulez être tranquille avec vos applications blindez votre code au maximum ! Ce que j'entend par "blinder" c'est ne laisser passer aucune erreur !
J'ai souvent entendu l'argument fallacieux suivant : "Oui mais ça risque de bloquer le client !"
Ce à quoi je répond : "Tu préfères qu'il sorte une balance fausse ton client, pauvre pomme ?" (Vous pouvez remplacer "pauvre pomme" par "banane" ou autre)
J'ai vu des problèmes terribles en clientèle, par exemple éditer 100 factures et se rendre compte lors de l'expédition que l'adresse de l'emetteur n'est pas la bonne ! Ah oui c'est certain, ils avaient pû éditer leurs factures !
Les conseils pratiques de l'Ancien :
Dès qu'une recherche n'aboutit pas alors qu'elle devrait trouver quelque chose ne pas aller plus loin : il y'a un soucis ! Au contraire si le code continue à s'exécuter il risque d'aggraver les choses ... un peu comme si on continuait à rouler avec un pneu crevé ou sans huile dans le moteur.
Tester systématiquement les plages de valeurs autorisées, par exemple avec des sélecteurs. Si la valeur doit être 1,2 ou 3 et qu'elle retourne 4 ou -1 ça signifie qu'il y a eu un problème en amont : signalez le et n'allez pas plus loin !
Plus un programme informera rapidement sur ses dysfonctionnements, plus ce sera simple de trouver et de solutionner le problème !
Exemple :
Voici l'exemple typique de code "passoire" :
- Si le HlitRecherche() n'aboutit pas on se positionne sur n'importe quel enregistrement de CLIENT.
- Sachant que CLI_TYPE doit être 1 ou 2, s'il vaut 0 ou -72 il sera considéré comme type 2.
- Si la requête ne fonctionne pas pour une raison ou pour une autre on aura dans le meilleur des cas un plantage Windev.
Et voici l'exemple d'un code qui ne laisse rien passer, à la moindre erreur on arrête tout ! Il est certes possible de travailler de manière plus subtile en activant la gestion des exceptions, qui permet de fermer une fenêtre ou d'interrompre un traitement sans quitter l'application.
Faire preuve d'honnêteté :
Ca signifie qu'il ne faut rien dissimuler dans les programmes ! A mon avis il n'y a rien de pire qu'une application qui semble bien fonctionner (pas de message d'erreur, pas de plantage) et qui fait n'importe quoi derrière : création d'enregistrements en trop, cumuls faux, mauvaise affectation des valeurs, etc...
Faire preuve d'humilité :
Personne n'est à l'abri de faire des bétises, surtout en matière de développement ! Il suffit de confondre une zone avec une autre, d'oublier de transformer un entier en chaine, d'inverser un opérateur relationnel, etc... Plus vous blindez votre code, plus ces petites erreurs sont facilement détectables lors de vos tests !
Effets de bord :
Ce qui est sencé fonctionner avec des données exactes risque de produire n'importe quoi avec des données fausses ! Par exemple un état X peut être parfaitement développé, sans aucun bug et fournir des résultats incorrects à cause de données corrompues, ces données ayant été corrompues lors d'un traitement qui n'a rien à voir ! Le développeur de l'état n'y peut rien ... et pourtant on aura tendance à dire "C'est l'état X qui ne fonctionne pas !" ... alors que c'est la gestion Z qui est à revoir !