Dans le développement d'un grand projet de programmation C ++ avec de nombreux développeurs, nous avons rencontré des problèmes avec une utilisation inappropriée de Assert () dans le code qui entraîne une mauvaise qualité lorsque l'affirmation se produit effectivement et le produit se bloque.
La question est de savoir ce qui sont de bons principes à appliquer pour utiliser Aster () de manière appropriée? Quand est-ce approprié d'utiliser une assertion () et quand n'est-ce pas? Existe-t-il une liste de critères que chaque assertion devrait réussir pour être légitime? Comment pouvons-nous encourager une utilisation appropriée de Aster ()?
comme une première fissure à cela, je dirais que cela ne devrait être utilisé que pour documenter une condition qui est considérée comme impossible à atteindre et qui devrait être identifiée comme une défaillance d'affirmation () au moment de l'exécution du moment où elle surgir parce que les hypothèses de programmation sont violées.
Les gens peuvent-ils faire mieux que cela? Quelle est votre expérience avec assert ()?
4 Réponses :
Vous devez utiliser ASSERT pour vérifier toutes les conditions qui ne devraient jamais arriver:
Mais vous devez inclure ces affirmations uniquement dans les bâtiments de débogage ou lorsqu'ils sont explicitement activés pour la libération (pas dans les bâtiments libérés aux clients).
Si les mauvaises conditions préalables, etc. sont du code complètement sous votre contrôle que d'échouer une affirmation conviennent parfaitement. Mais qu'en est-il des situations comme celles-ci: DLL manquantes / mauvaises DLL, mauvaises entrées de registre, etc.
Utilisez Utilisez
J'utilise des asserts pour vérifier tout état de programme indésirable :
Notez que "l'état du programme indésirable" exclut les erreurs qui se produisent naturellement au moment de l'exécution, telles que la possibilité d'ouvrir un fichier sélectionné par l'utilisateur en raison de l'autorisation ou de l'échec HD. Dans ces cas, il n'est pas sage d'utiliser des assertions.
GLDRAWARRAY (); CheckopenglLerror (); - CheckOpenglLerror () appelle getglerror () si allumé
affirmation (quelque chose == null);
Beaucoup de code de nos jours a beaucoup de dépendances externes et de connexions. Je n'ai pas tendance à utiliser beaucoup d'affirmations traditionnelles ces jours-ci, je privilégie les exceptions. Je n'ai pas envie de pouvoir assumer "cela ne peut jamais arriver" et les chèques peuvent être supprimés en toute sécurité dans une construction sans débogage.
Utilisez ASPERT lorsque vous savez que certaines conditions doivent prévaloir pour que le code soit considéré comme "bon". Si l'affirmation échoue, alors par définition, le code doit être corrigé.
@RObert: convenu +1, mais il doit y avoir une considération donnée à la quantité de travail que l'utilisateur perdra si l'affirmation de tir collait le programme. Il est gênant lorsqu'un navigateur perd un ensemble d'onglets ouverts, mais pas généralement une catastrophe; C'est un désastre si un traitement de texte perd une journée de travail en raison d'une affirmation. Les parties dures sont (a) de déterminer s'il est prudent de faire quoi que ce soit, et (b) de garder le système dans un état où il peut être récupéré si quelque chose ne va pas.
Celui qui va toute une journée sans sauver son travail obtient ce qu'il mérite quand une affirmation se produit.