Votre analyse préliminaire est un modèle du genre. Votre interface est originale, éblouissante même. Vous avez compilé et testé une dérnière fois. Et ca marche. Que diriez vous de lui faire passer l'épreuve des 50 points pour voir s'il peut affronter sans crainte le vaste Monde? Cette liste n'est pas complète. Mais si votre oeuvre survit déjà au crash-test suivant, vous aurez assuré à votre logiciel un meilleur départ.

Structure :
  • Vous avez effectué une compilation. Son résultat est il exempt de messages d'avertissement?
  • Avez vous implémenté toutes les spécifications prévues à l'analyse?
  • Reste-t-il des procedures ou fonctions qui ne sont ni nécessaires ni appelées?
  • Certaines routines ne seraient-elles pas avantageusement remplacées par des appels à des composants externes ou à des fonctions de l'API?
  • Le flux du programme suit-il l'ordre prévu?
  • Les temps d'éxecutions ont-ils été optimisés? Seront-ils acceptables pour l'utilisateur final? Celui-ci est il avert du bon déroulement et du succès d'une opération plus longue?
  • Le code est-il bien structuré, d'un style consistant, indenté de manière cohérente?
  • Certains blocs répétitifs ne pourrait-ils pas être condensés en une seule routine?
  • L'emploi de la mémoire est il efficace?
  • Si des procedure possède un degré cyclomatique supérieur à 15, pourquoi ne pas les éclater en plusieurs sous-proceudre plus simples?
  • Vos routines contiennent-elles un test systématique de validité des valeurs d'entrée?
Variables :
  • Toutes les variables sont-elles correctement déclarrées?
  • Chaque variable déclarée n'a -t-elle qu'une seule signification, une seule destination?
  • Ont-elles toutes un nom clair, précis, adhérant à un standard?
  • Toutes les variables assignées sont-elles du type approprié?
  • Les variables ont-elles des noms plus significatif que 'i' ou 'x'?
  • Reste-t-il des variables inutilisées?
  • Avez-vous évité les variables pseudo-globales, ces fourre-tout de taille mémoire parfois importante passés à chaque sous routine?
  • Toutes les références aux tableaux sont-elles dans les limites de ceux-ci?
Documentation :
  • Le code est il clairement documenté et de manière lisible?
  • Subsiste-t-il des inchohérences entre le code et les explicationsqui s'y rappportent?
  • Les commentaires sont-ils simples à lire et à maintenir?
Opérations arithmétiques :
  • Avez-vous évitez de comparrer l'égalité de deux nombre en virgule flottante?
  • Vos routines préviennent-elles systematiquement les erreurs d'arrondi?
  • Avez vous pensé que certaines opérations portant sur des entiers ont sujettes à problèmes? (les multiplication qui peuvent provoquer un overflow)
  • Avez vous évité d'opérer des additions ou des soustractions sur des nombre de magnitude trop différente?(1000000 et 0.0001 par exemple)
  • Toutes les opérations impliquant des nombres donnent-elles des résultats corrects et vérifiés?
  • Avez-vous évité des comparaisons impliquant des nombres de types différénts?
  • Des conversions adéquates sont-elles opérées dans ce dernier cas, évitant à votre compilateur de calculer ce micmac à votre place?
Boucles et branchements :
  • Toutes les boucles et structures logiques sont-ils correctement initialisés et terminés?
  • Sont-ils aussi, si c'est le cas, correctement imbriqués, à un maximum de trois niveaux?
  • Tous les cas impliqués dans un IF sont-ils traité, y compris les clauses ELSE, DEFAULT?
  • La fin de chaque déclaration CASE en Delphi a-t-elle un End?
  • La fin d'une boucle est-elle évidente et systématiquement atteinte lors du déroulement réel du programme?
  • Les index et compteurs de tableau sont-ils bien initialisées avant une boucle?
Programmation défensive :
  • Les index, pointeurs et compteurs sont-ils testés part rapport aux limites des tableaux, des tables ou des fichiers?
  • Les données et valeurs d'entrée sont-elles testées au point de vue validité et complétude?
  • Les divisions par 0 sont elles testées de manière anticipative?
  • Toutes les variables de sortie sont-elles assignées?
  • Avez-vous employé des type énumérés quand cela est possible, augmentant la souplesse, la lisibilité et la fiabilité du code?
  • Chaque allocation de mémoire est elle libérée?
  • Un test de dépassement de temps et une gestion d'erreur sont-ils mis systématiquement en place pour chaque accès à des phériphérique externes?
  • L'existence d'un fichier est-elle bien vérifiée avant d'en tenter l'accès?
  • Des routines de nettoyage sont-elles utilisées pour confirmer que tous les fichiers et périphériques sont laissés dans un état correct à la fin du programme?
  • Si des multiples points de sortie se trouvent dans une procedure, chacun d'eux éxecute-t-il les routines de nettoyage adéquates?
Cette liste devrait faire partie de votre documentation de programmeur. Vérifiez et revérifiez votre code. Il doit être clair et lisible. Prévoyer l'évolution de votre logiciel. Enfin, testez, re-testez et testez encore, c'est le seul moyen d'avoir un programme opérationnel.



Retour au sommaire