Mieux vaut prévenir que guérir

Les concepteurs du langage Ada ont cherché à appliquer un principe : il était préférable que les erreurs des développeurs soient repérées le plus tôt possible. Outre le fait qu'Ada a été défini pour le travail en équipes grâce à la répartition en paquetages dont les dépendances sont limitées (interfaces) et explicitement connues, c'est un descendant de Pascal qui utilise des types de données rigoureusement séparés (il est même plus strict que son ancêtre sur ce point). La syntaxe des programmes sources devait aussi permettre de restreindre le nombre d'erreurs passant une première étape : la compilation. En cela il est très éloigné du langage Cobol, largement utilisé.

Quand un exécutable vient d'être obtenu, les développeurs peuvent employer un outil de mise au point (debugger) qui visualise, éventuellement instruction par instruction, son fonctionnement et les changements des valeurs des données utilisées, permettant ainsi de repérer encore d'autres problèmes qui ont pu échapper au compilateur. En fait Ada intègre des mécanismes (déconnectables) de vérification pendant l'exécution pour faciliter la mise au point même sans debugger. Ainsi, il ne sera pas possible d'affecter à une variable ayant été déclarée pour stocker une valeur pouvant aller de 1 à 1000 un nombre en dehors de cet intervalle sans que le programme s'arrête brusquement en le signalant. Le C, entre autre, ne réalise pas de telles vérifications (il ne permet même pas de définir des variables avec un intervalle).

Une fois que les plâtres ont été essuyés pendant une mise au point plus ou moins longue, la nouvelle application peut être exploitée. Cela ne signifie pas pour autant que la fiabilité soit garantie. Des erreurs ayant passé les étapes de la conception peuvent n'être repérées qu'au bout d'un certain temps d'utilisation (ou même passer inaperçues). Il faudra alors les corriger avec toutes les difficultés que cela suppose pour les localiser précisément, surtout si elles viennent de cas particuliers. En fait, plus une erreur apparaît tard dans le processus d'écriture et d'utilisation, plus la somme de travail pour y remédier est importante.