Méthode de refactoring avec plusieurs instructions de retour conditionnelles

Question

J'ai une méthode pour la validation qui a beaucoup d'instructions conditionnelles. Fondamentalement, cela va

If Check1 = false 
    return false 
If Check2 = false 
    return false 
etc 

FxCop se plaint que la complexité cyclomatique est trop élevée. Je sais que ce n'est pas la meilleure pratique d'avoir des instructions de retour au milieu des fonctions, mais en même temps la seule alternative que je vois est une liste moche d'instructions If-else. Quelle est la meilleure façon d'aborder cela?

Merci d'avance.

Answer 1

Je ne suis pas d'accord avec votre affirmation selon laquelle il n'est pas recommandé d'avoir des instructions de retour au milieu des méthodes. La longueur de certaines personnes pour avoir une seule déclaration de retour est fou - aller avec tout ce qui produit le code le plus lisible. Parfois, ce sera un seul point de retour, mais souvent je trouve qu'il y a un "early out" - et il vaut mieux avoir ce retour que d'introduire plus de nidification dans le code avec un if pour le chemin alternatif. J'aime les méthodes qui ne finissent pas en retrait trop loin, en règle générale :)

Après avoir dit cela, est-ce vraiment la méthode rien mais vérifie? Les contrôles sont-ils indépendants? Quelles variables ont-ils besoin? Pouvez-vous les regrouper en méthodes plus petites représentant les «zones» des contrôles que vous effectuez?

Answer 2

En utilisant votre exemple:

return (Check1 == false) || (Check2 == false) [ || etc ] 

Answer 3

Pour votre cas particulier, il semble que vous pourriez probablement utiliser une boucle ... en supposant que cela est sorti d'un gestionnaire d'événements dans un formulaire ou quelque chose:

For Each ctrl As Control In Me.Controls 

    Dim check As CheckBox = TryCast(ctrl, CheckBox) 

    If check IsNot Nothing AndAlso check.Checked = False Then 
     Return False 
    End If 

Next 

Return True 

Edit: Après un examen plus approfondi, je me rends compte que cela était basé sur psuedocode et que vous n'utilisiez pas de cases à cocher. Cependant, je pense que la même méthodologie s'applique. Vous pouvez très facilement refactoriser vos règles dans une classe séparée qui implémente une interface personnalisée (IRule ou similaire), ou avoir une liste de délégués qui renvoient true/false que vous parcourez dans le cadre de votre modèle de vérification.

Answer 4

Si vous avez plusieurs contrôles de suite et ne pas besoin de conserver un court-circuit, vous pouvez essayer quelque chose comme ceci:

 bool isValid = true; 
     isValid &= Condition1; 
     isValid &= Condition2; 
     isValid &= Condition3; 
     if (!isValid) 
      return false; 

Si vous avez besoin de conserver un court-circuit, vous pouvez consolider les conditions dans une grande déclaration if. S'il y a beaucoup de conditions, cependant, je préférerais le code original, avec des retours multiples, comme un grand 'si' pourrait devenir un peu moche. Notez que, dans ce dernier cas, vous ne faites que contourner la métrique, car la branche logique est en fait la même. Si les vérifications de condition n'ont pas d'effets secondaires (et j'espère vraiment qu'elles ne le sont pas), je pense que la complexité cyclomatique élevée est une fausse alarme, car les retours multiples sont vraiment une manière plus lisible d'exprimer une logique de validation booléenne complexe.

Ceci n'est vrai que si les conditions sont toutes en série. Si elles sont réparties dans le code, avec un traitement significatif entre les vérifications, alors la métrique indique une réelle complexité (plus de branches qui doivent être testées). Dans ce cas, vous pouvez déterminer si la méthode peut être divisée logiquement en éléments plus petits et individuellement testables.