Cadre de code robuste?

Question

Je déteste écrire du code qui rend mon logiciel plus solide. C'est quelque chose aurait dû faire le cadre! Alors, est tout le monde au courant d'un code « amélioration » utilitaire qui solidifie le code?

Si je devais créer quelque chose de moi-même, ce serait comme cela fonctionne comme suit: Lorsque vous compilez votre code avec un drapeau de débogage, il ajouterions automatiquement par magie code « solidifiant » pour chaque méthode:

gauchir le code avec un try-catch et de mettre un Debug.Assert (vrai) dans la prise (de sorte que les exceptions sont pris à leur origine).

entrée du journal de chaque méthode, l'impression « ToString () » valeurs d'arguments, donc je peux retracer ce qui se passe.

Vérifiez chaque argument NULL.

Utilisez un cadre « IsValid » pour vérifier l'objet lui-même et chaque argument, où IsValid () est la manière de l'objet de déclarer que ses attentes sont vraies (par exemple, si je suis un TableOfContentsEntry Je pense toujours être dans un livre qui est IsValid () et de pointer vers une page qui est IsValid ().

Alors, pourquoi pas?

Answer 1

Si vous souhaitez enregistrer les appels de méthode, vous pouvez utiliser un cadre d'AOP comme PostSharp . Des choses comme méthode application pré / postconditions seraient mieux atteints en utilisant des mécanismes de conception par contrat comme le nouveau code des marchés bibliothèque qui sera livré avec .net4.0. Il n'a certainement pas de sens pour vérifier que des arguments pour nuls car cela peut être une valeur valide selon la méthode. Debug.Asserts dans le code d'injection pourrait être problématique puisque vous voudrez peut-être pas / être en mesure de gérer les exceptions dans la fonction source. Je pense qu'il serait peu pratique, voire impossible, de créer un cadre générique pour ce genre de chose car les exigences diffèrent tellement entre les projets.

EDIT: Pour clarifier mon commentaire sur l'ajout d'assertions de débogage dans les méthodes - J'ai lu votre proposition de convertir un corps de méthode en quelque chose comme ceci:

public void SomeMethod(args)
{
    try
    {
        //original method body
    }
    catch(Exception ex)
    {
        Debug.Assert(false);
        throw;
    }
}

Le problème est que Affirme indiquent des choses qui ne devraient jamais être faux - si cette construction signifie que la méthode ne peut jamais jeter ce qui est faux en général. Le problème est maintenant que si la méthode ne jette, l'affirmation échouera même si la méthode d'appel traite de façon appropriée l'exception. De votre commentaire, il semble que vous faites quelque chose comme ceci:

public void SomeMethod(object arg)
{
    Debug.Assert(arg != null);
    if(arg == null) throw new ArgumentNullException("arg");

    //rest of method
}

Ceci est une pratique utile, et je crois que le code des contrats de condition sine qua non de l'héritage »des supports de la bibliothèque de contrôle (exceptions) de lancer dans son analyse statique.

Answer 2

Il est agréable de voir mon livre étant branché! Le gros problème pour moi est que je pense que la génération de code devrait viser à être « à côté de » code de développeur - i.e.. idéalement, le code généré ne serait pas entremêlé avec le code du développeur. Je me demande s'il y a un moyen d'ajouter ce code « solidfying » en tant que classe partielle ou comme mandataire qui fixerait entre la classe et le client qui a été l'appeler? Bien sûr, il est certainement possible de générer le code et l'insérer dans le code du développeur, mais vous voudriez créer une sorte de convention de sorte que lorsque le développeur fait un changement et regénère le code « soldifying », l'outil pourrait supprimer l'ancien code et générer un nouveau code basé sur la dernière version du code du développeur.

Answer 3

J'aimerais quelque chose qui ne perd pas votre pile lorsque vous passez quelque chose hors d'un thread de travail. Je ne sais même pas d'une solution de contournement pour cela (C #). Ce serait génial de connaître la pile du fil parent jusqu'au point où le thread de travail a été créé.

En général, je pense que beaucoup des choses vraiment utiles devrait être construit dans une langue et ne peut pas vraiment être atteint proprement par une bibliothèque ou d'un cadre seul. Je me souviens au lycée, ils ont appris à écrire toujours dans des conditions pré / post dans les commentaires pour une fonction, mais ce que je voudrais vraiment voir est écrit avant / conditions post cochés si possible au moment de la compilation, sinon, à exécution. Ils seraient marqués d'une manière telle qu'un éditeur peut éventuellement afficher ou les masquer de sorte qu'il ne soit pas dans la façon de lire le code réel.

Answer 4

Je doute qu'il y ait quelque chose comme ça et si, alors il est sûr pas utilisable. Cela dépend de vos définitions de règles, différentes personnes pensent différentes, ont des besoins et des cadres différents ... Les choses que vous avez décrites pourraient être atteints par metaprogramming ou un système macro. En Java, il y a quelques projets qui pourraient contribuer à mettre en œuvre une telle approche annotations usign, ne sais pas s'il y a quelque chose d'équivalent dans l'univers C #. La fonctionnalité isValid () ressemble cependant à peu près comme la conception par l'idée de contrat, peut-être il y a des cadres pour cela.