Comment puis-je éditer une chaîne d'instructions if-else if pour adhérer aux principes de code propre d'Oncle Bob?

J'essaie de suivre les suggestions de code propre d'Oncle Bob et en particulier de garder les méthodes courtes.

Je me trouve cependant incapable de raccourcir cette logique:

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

Je ne peux pas enlever les elses et donc séparer le tout en petits morceaux, provoquer le "else" dans le "else si" aide à la performance - évaluer ces conditions coûte cher et si je peux éviter d'évaluer les conditions ci-dessous, provoquer l'un des premiers est vrai, je veux les éviter.

Même sémantiquement parlant, évaluer la prochaine condition si la précédente était remplie n’a pas de sens du point de vue commercial.

edit: Cette question a été identifiée comme un doublon possible de façons élégantes de traiter si (sinon) autre chose .

Je pense que la question est différente (vous pouvez le constater également en comparant les réponses de ces questions).

• Ma question vérifie que la première condition d'acceptation se termine rapidement .
• La question liée est d'essayer d'avoir toutes les conditions à accepter pour faire quelque chose. (mieux vu dans cette réponse à cette question: https://softwareengineering.stackexchange.com/a/122625/96955 )

Idéalement, je pense que vous devriez extraire votre logique pour obtenir le code / numéro d'alerte dans sa propre méthode. Donc, votre code existant est réduit jusqu’à

{
    addAlert(GetConditionCode());
}

et GetConditionCode () encapsule la logique pour vérifier les conditions. Peut-être aussi mieux d'utiliser un Enum qu'un nombre magique.

private AlertCode GetConditionCode() {
    if (CheckCondition1()) return AlertCode.OnFire;
    if (CheckCondition2()) return AlertCode.PlagueOfBees;
    if (CheckCondition3()) return AlertCode.Godzilla;
    if (CheckCondition4()) return AlertCode.ZombieSharkNado;
    return AlertCode.None;
}

La mesure importante est la complexité du code, pas la taille absolue. En supposant que les différentes conditions ne sont en réalité que des appels à une seule fonction, tout comme les actions ne sont pas plus complexes que ce que vous avez montré, je dirais que le code ne présente aucun défaut. C'est déjà aussi simple que possible.

Toute tentative de simplification supplémentaire compliquera les choses.

Bien sûr, vous pouvez remplacer le elsemot - clé par un mot returncomme d'autres l'ont suggéré, mais il ne s'agit que d'une question de style, pas de changement de complexité.

De côté:

Mon conseil général serait de ne jamais devenir religieux avec une règle de code propre: la plupart des conseils de codage que vous voyez sur Internet sont bons s'ils sont appliqués dans un contexte approprié, mais l'application radicale de ces mêmes conseils partout peut vous faire gagner une entrée l' IOCCC . L'astuce consiste toujours à trouver un équilibre qui permette aux êtres humains de raisonner facilement sur votre code.

Utilisez trop de méthodes, et vous êtes foutus. Utilisez des fonctions trop petites et vous êtes foutus. Évitez les expressions ternaires, et vous êtes foutu. Utilisez des expressions ternaires partout et vous êtes foutus. Réalisez qu'il existe des endroits qui appellent des fonctions sur une ligne et des endroits qui appellent des fonctions à 50 lignes (oui, ils existent!). Sachez qu'il y a des endroits qui appellent des if()déclarations et des endroits qui appellent des ?:opérateurs. Utilisez tout l'arsenal à votre disposition et essayez de toujours utiliser l'outil le plus adapté que vous puissiez trouver. Et rappelez-vous, ne devenez pas religieux même à propos de ce conseil.

Il est controversé de savoir si cela est «meilleur» que la plaine, si ..else pour un cas donné Mais si vous voulez essayer autre chose, c'est une façon courante de le faire.

Mettez vos conditions dans des objets et mettez ces objets dans une liste

foreach(var condition in Conditions.OrderBy(i=>i.OrderToRunIn))
{
    if(condition.EvaluatesToTrue())
    {
        addAlert(condition.Alert);
        break;
    }
}

Si plusieurs actions sont requises à condition que vous puissiez faire une récursion folle

void RunConditionalAction(ConditionalActionSet conditions)
{
    foreach(var condition in conditions.OrderBy(i=>i.OrderToRunIn))
    {
        if(condition.EvaluatesToTrue())
        {
            RunConditionalAction(condition);
            break;
        }
    }
}

Évidemment oui. Cela ne fonctionne que si vous avez un modèle dans votre logique. Si vous essayez d'effectuer une action conditionnelle récursive super générique, la configuration de l'objet sera aussi compliquée que l'instruction if d'origine. Vous allez inventer votre propre nouveau langage / framework.

Mais votre exemple ne un modèle

Un cas d'utilisation courant pour ce modèle serait la validation. Au lieu de :

bool IsValid()
{
    if(condition1 == false)
    {
        throw new ValidationException("condition1 is wrong!");
    }
    elseif(condition2 == false)
    {
    ....

}

Devient

[MustHaveCondition1]
[MustHaveCondition2]
public myObject()
{
    [MustMatchRegExCondition("xyz")]
    public string myProperty {get;set;}
    public bool IsValid()
    {
        conditions = getConditionsFromReflection()
        //loop through conditions
    }
}

Pensez à utiliser return;après une condition a réussi, il vous sauve tous les elses. Vous pourriez même pouvoir return addAlert(1)directement si cette méthode a une valeur de retour.

J'ai parfois vu des constructions comme celle-ci considérée comme plus propre:

switch(true) {
    case cond1(): 
        statement1; break;
    case cond2():
        statement2; break;
    case cond3():
        statement3; break;
    // .. etc
}

Ternary avec un bon espacement peut également être une alternative intéressante:

cond1() ? statement1 :
cond2() ? statement2 :
cond3() ? statement3 : (null);

J'imagine que vous pourriez également essayer de créer un tableau avec une paire contenant une condition et une fonction et l'itérer jusqu'à ce que la première condition soit remplie - ce qui, à mon avis, équivaudrait à la première réponse d'Ewan.

Comme variante de la réponse de @ Ewan, vous pouvez créer une chaîne (au lieu d'une "liste simple") de conditions telles que:

abstract class Condition {
  private static final  Condition LAST = new Condition(){
     public void alertOrPropagate(DisplayInterface display){
        // do nothing;
     }
  }
  private Condition next = Last;

  public Condition setNext(Condition next){
    this.next = next;
    return this; // fluent API
  }

  public void alertOrPropagate(DisplayInterface display){
     if(isConditionMeet()){
         display.alert(getMessage());
     } else {
       next.alertOrPropagate(display);
     }
  }
  protected abstract boolean isConditionMeet();
  protected abstract String getMessage();  
}

De cette façon, vous pouvez appliquer vos conditions dans un ordre défini et l'infrastructure (la classe abstraite affichée) ignore les vérifications restantes une fois la première rencontrée.

C’est là où il est supérieur à l’approche "liste plate" dans laquelle vous devez implémenter le "saut" dans la boucle qui applique les conditions.

Vous configurez simplement la chaîne de conditions:

Condition c1 = new Condition1().setNext(
  new Condition2().setNext(
   new Condition3()
 )
);

Et commencez l'évaluation avec un simple appel:

c1.alertOrPropagate(display);

Tout d'abord, le code d'origine n'est pas terrible OMI. C'est assez compréhensible et il n'y a rien de mauvais en soi.

Ensuite, si vous n’aimez pas cela, développez l’idée de @ Ewan d’utiliser une liste en supprimant son foreach breakmotif quelque peu anormal :

public class conditions
{
    private List<Condition> cList;
    private int position;

    public Condition Head
    {
        get { return cList[position];}
    }

    public bool Next()
    {
        return (position++ < cList.Count);
    }
}


while not conditions.head.check() {
  conditions.next()
}
conditions.head.alert()

Adaptez maintenant ceci dans la langue de votre choix, faites de chaque élément de la liste un objet, un tuple, peu importe, et vous serez doué.

EDIT: il semble que ce ne soit pas aussi clair que je le pensais, alors laissez-moi vous expliquer davantage. conditionsest une liste ordonnée de quelque sorte; headest l’élément en cours d’investigation - au début c’est le premier élément de la liste, et chaque fois next()qu’on l’appelle, il devient le suivant; check()et alert()sont le checkConditionX()et addAlert(X)de l'OP.

La question manque de quelques détails. Si les conditions sont:

• sujet à changement ou
• répété dans d'autres parties de l'application ou du système ou
• modifié dans certains cas (tels que différentes versions, tests, déploiements)

ou si le contenu de addAlertest plus compliqué, alors une meilleure solution, par exemple, de c # serait:

//in some central spot
IEnumerable<Tuple<Func<bool>, int>> Conditions = new ... {
  Tuple.Create(CheckCondition1, 1),
  Tuple.Create(CheckCondition2, 2),
  ...
}

//at the original place
var matchingCondition = Conditions.Where(c=>c.Item1()).FirstOrDefault();
if(matchingCondition != null) 
  addAlert(matchingCondition.Item2)

Les tuples ne sont pas si beaux en c # <8, mais choisis pour leur convenance.

Les avantages de cette méthode, même si aucune des options ci-dessus ne s’appliquent, est que la structure est typée de manière statique. Vous ne pouvez pas accidentellement bousiller par, par exemple, manquer un else.

Le meilleur moyen de réduire la complexité de Cyclomatic dans les cas où vous en avez beaucoup if->then statementsest d'utiliser un dictionnaire ou une liste (dépendant de la langue) pour stocker la valeur de clé (si valeur d'instruction ou une valeur de), puis un résultat valeur / fonction.

Par exemple, au lieu de (C #):

if (i > 10) { return "Two"; }
else if (i > 8) { return "Four" }
else if (i > 4) { return "Eight" }
return "Ten";  //etc etc say anything after 3 or 4 values

Je peux simplement

var results = new Dictionary<int, string>
{
  { 10, "Two" },
  { 8, "Four"},
  { 4, "Eight"},
  { 0, "Ten"},
}

foreach(var key in results.Keys)
{
  if (i > results[key]) return results.Values[key];
}

Si vous utilisez des langues plus modernes, vous pouvez stocker plus de logique que simplement des valeurs (c #). C’est vraiment juste des fonctions en ligne, mais vous pouvez aussi simplement indiquer d’autres fonctions si la logique est de les mettre en ligne.

var results = new Dictionary<Func<int, bool>, Func<int, string>>
{
  { (i) => return i > 10; ,
    (i) => return i.ToString() },
  // etc
};

foreach(var key in results.Keys)
{ 
  if (key(i)) return results.Values[key](i);
}

J'essaie de suivre les suggestions de code propre d'Oncle Bob et en particulier de garder les méthodes courtes.

Je me trouve cependant incapable de raccourcir cette logique:

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

Votre code est déjà trop court, mais la logique elle-même ne devrait pas être modifiée. À première vue, il semble que vous vous répétiez avec quatre appels à checkCondition(), et il est évident que chacun est différent après avoir relu attentivement le code. Vous devez ajouter un formatage approprié et des noms de fonction, par exemple:

if (is_an_apple()) {
  addAlert(1);
}
else if (is_a_banana()) {
  addAlert(2);
}
else if (is_a_cat()) {
  addAlert(3);
}
else if (is_a_dog()) {
  addAlert(4);
}

Votre code doit être lisible avant tout. Ayant lu plusieurs livres de mon oncle Bob, je crois que c’est le message qu’il cherche constamment à faire passer.

En supposant que toutes les fonctions soient implémentées dans le même composant, vous pouvez les conserver dans un état afin de vous débarrasser des multiples branches du flux.

EG: checkCondition1()deviendrait evaluateCondition1(), sur lequel il vérifierait si la condition précédente était remplie; si tel est le cas, il met en cache une valeur à récupérer getConditionNumber().

checkCondition2()deviendrait evaluateCondition2(), sur lequel il vérifierait si les conditions précédentes étaient remplies. Si la condition précédente n'était pas remplie, il vérifie le scénario de condition 2, mettant en cache une valeur à récupérer getConditionNumber(). Etc.

clearConditions();
evaluateCondition1();
evaluateCondition2();
evaluateCondition3();
evaluateCondition4();
if (anyCondition()) { addAlert(getConditionNumber()); }

MODIFIER:

Voici comment la vérification des conditions coûteuses devrait être mise en œuvre pour que cette approche fonctionne.

bool evaluateCondition34() {
    if (!anyCondition() && A && B && C) {
        conditionNumber = 5693;
        return true;
    }
    return false;
}

...

bool evaluateCondition76() {
    if (!anyCondition() && !B && C && D) {
        conditionNumber = 7658;
        return true;
    }
    return false;
}

Par conséquent, si vous avez trop de contrôles coûteux à effectuer et que les éléments de ce code restent confidentiels, cette approche permet de le maintenir, ce qui permet de modifier l'ordre des contrôles si nécessaire.

clearConditions();
evaluateCondition10();
evaluateCondition9();
evaluateCondition8();
evaluateCondition7();
...
evaluateCondition34();
...
evaluateCondition76();

if (anyCondition()) { addAlert(getConditionNumber()); }

Cette réponse fournit simplement quelques suggestions alternatives des autres réponses, et ne sera probablement pas meilleure que le code d'origine si nous considérons seulement 4 lignes de code. Bien que ce ne soit pas une approche terrible (et ne rend pas la maintenance plus difficile, comme d’autres l'ont dit) compte tenu du scénario que j'ai mentionné (trop de contrôles, seule fonction principale exposée en tant que public, toutes les fonctions sont des détails de mise en œuvre de la même classe).

Pas plus de deux clauses "else" obligent le lecteur du code à parcourir l'intégralité de la chaîne pour trouver celle qui présente un intérêt. Utilisez une méthode telle que: void AlertUponCondition (Condition condition) {switch (condition) {case Condition.Con1: ... break; case Condition.Con2: ... pause; etc ...} Où "Condition" est une énumération appropriée. Si nécessaire, renvoyez une valeur booléenne ou une valeur. Appelez comme ça: AlertOnCondition (GetCondition ());

Cela ne peut vraiment pas être plus simple ET c'est plus rapide que la chaîne if-else une fois que vous avez dépassé quelques cas.

Je ne peux pas parler de votre situation particulière car le code n'est pas spécifique, mais ...

Un code comme celui-ci est souvent une odeur de modèle OO manquant. Vous avez vraiment quatre types de choses, chacune associée à son propre type d’avertisseur, mais au lieu de reconnaître ces entités et de créer une instance de classe pour chacune d’elles, vous les traitez comme une seule chose et essayez de les rattraper plus tard, à un moment vraiment propice. besoin de savoir à quoi vous avez affaire pour pouvoir procéder.

Le polymorphisme pourrait vous convenir mieux.

Méfiez-vous du code avec les méthodes longues contenant des constructions if ou then longues ou complexes. Vous voulez souvent un arbre de classes avec des méthodes virtuelles.