Comment prévenir le "syndrome des gros doigts" en l'absence de req. prédécloration?

Question

Par exemple:

on rising edge (reset): 
sync = defaultValue; 
... 
... various processing constructs ... 
... 
if (event == someEvent) // Back at the Batcave 
    // The vilianous Fat finger Syndrome 
    // strikes again! 
    synch = someEventProcessing() 
... 
... various processing constructs ... 
... 
someSyncProcessing(sync) // Foiled again! 

toutes les occurences du varible "sync" aurait dû être orthographié "synchronisation" au lieu de "synch." Je lis même la ligne avec l'orthographe incorrecte et mon cerveau «tokenisé» c'est la signification symbolique.

J'ai regardé le code pendant quelques jours avant de trouver la faute de frappe. Comment empêchez-vous cela lorsque la langue ne génère aucune erreur? Il y avait un travail autour dans le code parce que quelqu'un ne pouvait pas trouver la source de la "magie noire" causant le comportement errant du programme. Cela a obscurci le problème encore plus. (Ce code était en fait paraphrasé à partir d'un programme verilog, mais il semble que cela puisse poser un problème dans n'importe quel langage autorisant ce type de problème.)

Answer 1

Si votre compilateur ne fournit pas d'outil permettant de détecter ce type de problème, tu n'as pas grand chose à espérer. Je recommanderais une politique de tests unitaires très stricte. Au moins, il sera plus facile de localiser l'apparition du syndrome.

Une stratégie possible (NB: possible) est de prendre tous les identifiants uniques, un par ligne (par exemple, remplacer tous les espaces par des retours), puis les filtrer à travers un tri | uniq. Il vous permettra, espérons-le, d'avoir une meilleure vue des identifiants étrangement typés.

Vous pouvez également réduire une telle occurrence en utilisant l'option de tabulation dans votre éditeur. vim, par exemple, a une fonction très utile (Mosh_tab_or_complete) pour effectuer une auto-complétion.

Answer 2

Tests unitaires. En utilisant TDD, vous écrivez des tests pour définir le comportement attendu, puis écrivez le code pour implémenter le comportement. Configurez vos attentes et simulez les objets, puis testez que les objets simulés ont les bonnes méthodes appelées. Vérifiez que vos données ont maintenant les bonnes valeurs.

Answer 3

N'oubliez pas de ralentir. Trop de programmeurs se précipitent et font des erreurs comme celle-ci. Je sais que l'écriture dans Verilog n'est pas très conviviale, donc il faut être très prudent dans ce cas.