10 Façons d'éviter les bogues en C ++ - des mannequins

Il est regrettable que vous passiez plus de temps à chercher et à supprimer des bogues que vous ne passerez réellement à écrire vos programmes C ++. Les suggestions ici peuvent vous aider à réduire le nombre d'erreurs que vous introduisez dans vos programmes pour faire de la programmation une expérience plus agréable.

Activer tous les avertissements et les messages d'erreur

La syntaxe de C ++ permet de nombreuses vérifications d'erreurs. Lorsque le compilateur rencontre une construction qu'il ne peut tout simplement pas déchiffrer, il n'a pas d'autre choix que de sortir un message. Il essaie de se synchroniser avec le code source (parfois avec moins de succès), mais il ne génère pas d'exécutable. Cela force le programmeur à corriger tous les messages d'erreur.

Cependant, quand C ++ rencontre une structure qu'il peut comprendre mais que la structure sent le poisson de toute façon, C ++ génère un message d'avertissement. Parce que C ++ est assez sûr qu'il comprend ce que vous voulez, il va de l'avant et crée un fichier exécutable afin que vous puissiez ignorer les avertissements si vous le souhaitez. En fait, si vous ne voulez vraiment pas être dérangé, vous pouvez désactiver les avertissements.

Désactiver ou ignorer les avertissements est une très mauvaise idée. C'est un peu comme si on débranchait le voyant «vérifier le moteur» sur le tableau de bord de votre voiture parce que cela vous dérange. Ignorer le problème ne le fait pas disparaître.

L'écriture d'un code C ++ dans un style clair et cohérent améliore non seulement la lisibilité de votre programme, mais entraîne également moins d'erreurs de codage. Cette situation quelque peu surprenante résulte du fait que notre cerveau n'a qu'une puissance de calcul limitée.

Lorsque vous lisez un code propre et soigné et qui suit un style que vous connaissez, vous passez très peu de temps à analyser la syntaxe des instructions C ++. Cela laisse plus de puissance CPU pour décoder ce que le programme essaie de faire et non comment il le fait.

Un bon style de codage vous permet de faire facilement les choses suivantes:

Différencier les noms de classe, les noms d'objet et les noms de fonction

Comprendre la classe, la fonction ou l'objet, en fonction de son nom
Différencier les symboles du préprocesseur des symboles C ++ (c'est-à-dire que les objets #define doivent ressortir)
Identifier les blocs de code C ++ au même niveau (résultat d'une indentation cohérente)
De plus, vous devez établir un format standard pour vos en-têtes de module qui fournit des informations sur les fonctions ou les classes de chaque module, l'auteur, la date, la version et quelque chose sur l'historique des modifications.

Tous les programmeurs impliqués dans un même projet doivent utiliser le même style de codage. Un programme écrit dans un patchwork de différents styles de codage est confus et semble non professionnel.

Commentez le code pendant que vous l'écrivez

Vous pouvez éviter les erreurs si vous commentez votre code pendant que vous l'écrivez, plutôt que d'attendre que tout fonctionne, puis revenez en arrière et ajoutez des commentaires.

La formulation de commentaires vous oblige à faire le point sur ce que vous essayez de faire. De brefs commentaires sont éclairants, à la fois lorsque vous les lisez plus tard et que vous les écrivez. Écrivez les commentaires comme si vous parliez à un autre programmeur bien informé.

Effectuer une seule étape dans le débogueur au moins une fois

En tant que programmeur, vous devez comprendre ce que fait votre programme. Il ne suffit pas que le programme génère la valeur attendue. Vous devez comprendre tout ce que fait votre programme. Rien ne vous donne une meilleure idée de ce qui se passe sous le capot que le programme

single-step , en l'exécutant pas à pas avec un bon débogueur (comme celui fourni avec Code:: Blocks). Au-delà de cela, lorsque vous déboguez un programme, vous avez besoin de données brutes pour comprendre un comportement bizarre qui pourrait apparaître lorsque le programme s'exécute. Rien ne vous donne plus de matière que de faire un pas à travers chaque fonction quand elle entre en service.

Enfin, lorsqu'une fonction est terminée et prête à être ajoutée au programme, chaque chemin logique doit être parcouru au moins une fois. Les bogues sont beaucoup plus faciles à trouver lorsque vous examinez la fonction par elle-même plutôt qu'après avoir été jeté dans le pot avec le reste des fonctions - d'ici là, votre attention s'est portée sur de nouveaux défis de programmation.

Limiter la visibilité

Limiter la visibilité des classes internes au monde extérieur est la pierre angulaire de la programmation orientée objet. La classe devrait être responsable de son état interne - si quelque chose se fout dans la classe, alors c'est la faute du programmeur de classe. Le programmeur d'application devrait s'inquiéter de résoudre le problème à portée de main.

Plus précisément, une visibilité limitée signifie que les membres des données ne devraient pas être accessibles en dehors de la classe - c'est-à-dire qu'ils devraient être marqués comme protégés. En outre, les fonctions membres que le logiciel d'application n'a pas besoin de connaître doivent également être marquées comme protégées. N'exposez pas plus d'éléments internes que nécessaire pour faire le travail.

Gardez une trace de la mémoire du tas

Perdre la mémoire de tas est la source la plus courante d'erreurs fatales dans les programmes qui ont été lancés sur le terrain - et, en même temps, le plus difficile à localiser. (Parce que cette classe d'erreur est si difficile à trouver et à supprimer, elle est répandue dans les programmes que vous achetez.) Vous devrez peut-être exécuter un programme pendant des heures avant que les problèmes ne surviennent (selon la taille de la fuite).

En règle générale, les programmeurs doivent toujours allouer et libérer la mémoire heap au même niveau. "Si une fonction membre MyClass:: create () alloue un bloc de mémoire tas et le renvoie à l'appelant, alors il doit y avoir un membre MyClass:: release () qui le renvoie au tas.Plus précisément, MyClass:: create () ne devrait pas exiger que la fonction parent libère la mémoire.

Dans la mesure du possible, MyClass doit garder la trace de ces pointeurs de mémoire et les supprimer dans le destructeur.

Mettre à zéro les pointeurs après avoir supprimé ce qu'ils pointent

Assurez-vous de mettre à zéro les pointeurs après qu'ils ne sont plus valides; vous le faites en leur affectant la valeur nullptr. Les raisons de cette action deviennent claires avec l'expérience: Vous pouvez continuer à utiliser un bloc de mémoire qui a été retourné au tas et même pas le savoir. Un programme peut fonctionner correctement 99 pour cent du temps, ce qui rend très difficile de trouver le 1 pour cent des cas où le bloc est réaffecté et le programme ne fonctionne pas.

Si vous annulez les pointeurs qui ne sont plus valides et que vous essayez de les utiliser pour stocker une valeur (vous ne pouvez pas stocker quoi que ce soit à ou près de l'emplacement nul), votre programme se bloque immédiatement. Crashing sonne mal, mais ce n'est pas si cela pose un problème. Le problème est là; c'est simplement une question de savoir si vous le trouvez ou non avant de le mettre en production.

Utiliser des exceptions pour gérer les erreurs

Le mécanisme d'exception de C ++ est conçu pour gérer les erreurs de manière pratique et efficace. En général, vous devriez lancer un indicateur d'erreur plutôt que de renvoyer un indicateur d'erreur. Le code résultant est plus facile à écrire, lire et maintenir. D'ailleurs, d'autres programmeurs en sont venus à s'y attendre, et vous ne voudriez pas les décevoir, n'est-ce pas?

Limitez votre utilisation des exceptions aux vraies erreurs. Il n'est pas nécessaire de lancer une exception à partir d'une fonction qui renvoie un indicateur "ne fonctionne pas" si cela fait partie de la vie quotidienne de cette fonction.

Déclarer les destructeurs virtuels

N'oubliez pas de créer un destructeur pour votre classe si le constructeur alloue des ressources telles que la mémoire de segment qui doit être retournée lorsque l'objet atteint sa fin ultime. Après avoir créé un destructeur, n'oubliez pas de le déclarer virtuel.

"Mais", vous dites, "ma classe n'hérite de rien, et elle n'est pas sous-classée par une autre classe. "Oui, mais ça

pourrait devenir une classe de base dans le futur. Sauf si vous avez une bonne raison de ne pas déclarer le destructeur virtuel, faites-le lors de la création de la classe. Fournissez un constructeur de copie et un opérateur d'affectation surchargé