Come posso modificare una catena di istruzioni if-else if per aderire ai principi del codice pulito di zio Bob?

Sto cercando di seguire i suggerimenti sul codice pulito di zio Bob e in particolare di mantenere i metodi brevi.

Mi trovo incapace di abbreviare questa logica però:

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

Non riesco a rimuovere gli altri e quindi a separare il tutto in bit più piccoli, causare "altro" in "else if" aiuta le prestazioni - la valutazione di tali condizioni è costosa e se posso evitare di valutare le condizioni di seguito, causa una delle prime è vero, voglio evitarli.

Anche semanticamente parlando, valutare la condizione successiva se la precedente fosse soddisfatta non ha senso dal punto di vista commerciale.

modifica: questa domanda è stata identificata come un possibile duplicato di modi eleganti per gestire if (if else) else .

Credo che questa sia una domanda diversa (puoi vederlo anche confrontando le risposte a tali domande).

• La mia domanda sta verificando che la prima condizione accettante finisca rapidamente .
• La domanda collegata sta cercando di avere tutte le condizioni per essere accettata per fare qualcosa. (meglio visibile in questa risposta a questa domanda: https://softwareengineering.stackexchange.com/a/122625/96955 )

Idealmente penso che dovresti estrarre la tua logica per ottenere il codice / numero di avviso nel suo metodo. Quindi il tuo codice esistente è ridotto fino a

{
    addAlert(GetConditionCode());
}

e hai GetConditionCode () incapsula la logica per il controllo delle condizioni. Forse anche meglio usare un Enum che un numero magico.

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 misura importante è la complessità del codice, non la dimensione assoluta. Supponendo che le diverse condizioni siano in realtà solo chiamate a funzione singola, proprio come le azioni non sono più complesse di quanto mostrato, direi che non c'è nulla di sbagliato nel codice. È già semplice come può essere.

Qualsiasi tentativo di "semplificare" ulteriormente complicherà le cose.

Ovviamente, puoi sostituire la elseparola chiave con una returncome altri hanno suggerito, ma è solo una questione di stile, non un cambiamento nella complessità.

A parte:

Il mio consiglio generale sarebbe di non essere mai religioso su nessuna regola per un codice pulito: la maggior parte dei consigli di codifica che vedi su Internet è buona se applicata in un contesto appropriato, ma applicare radicalmente lo stesso consiglio ovunque può farti entrare a far parte di l' IOCCC . Il trucco è sempre quello di trovare un equilibrio che consenta agli esseri umani di ragionare facilmente sul tuo codice.

Usa metodi troppo grandi e sei fregato. Usa funzioni troppo piccole e sei fregato. Evita le espressioni ternarie e sei fregato. Usa le espressioni ternarie dappertutto e sei fregato. Renditi conto che ci sono posti che richiedono funzioni a una linea e luoghi che richiedono funzioni a 50 linee (sì, esistono!). Comprendi che ci sono luoghi che richiedono if()dichiarazioni e che ci sono luoghi che richiedono l' ?:operatore. Usa l'arsenale completo a tua disposizione e cerca sempre di utilizzare lo strumento più adatto che riesci a trovare. E ricorda, non diventare religioso anche su questo consiglio.

È controverso se questo sia "migliore" del semplice if..else per un dato caso. Ma se vuoi provare qualcos'altro, questo è un modo comune di farlo.

Inserisci le tue condizioni negli oggetti e inseriscili in un elenco

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

Se sono necessarie più azioni a condizione, puoi fare una pazza ricorsione

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

Ovviamente sì. Funziona solo se hai un modello nella tua logica. Se si tenta di eseguire un'azione condizionale ricorsiva super generica, l'impostazione per l'oggetto sarà complicata come l'istruzione if originale. Inventerai il tuo nuovo linguaggio / quadro.

Ma il tuo esempio ha avere un modello

Un caso d'uso comune per questo modello sarebbe la convalida. Invece di :

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

}

diventa

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

Considera l'utilizzo return;dopo che una condizione è riuscita, ti fa risparmiare tutti elsei messaggi. Potresti anche essere in grado di farlo return addAlert(1)direttamente se quel metodo ha un valore di ritorno.

Ho visto costruzioni come questa considerate a volte più pulite:

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

Il ternario con la giusta spaziatura può anche essere un'alternativa chiara:

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

Suppongo che potresti anche provare a creare un array con coppia contenente condizione e funzione e iterare su di esso fino a quando non viene soddisfatta la prima condizione, che a mio modo di vedere sarebbe uguale alla prima risposta di Ewan.

Come variante della risposta di @ Ewan potresti creare una catena (anziché un "elenco semplice") di condizioni come questa:

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();  
}

In questo modo è possibile applicare le condizioni in un ordine definito e l'infrastruttura (la classe astratta mostrata) salta i controlli rimanenti dopo il primo incontro.

È qui che è superiore all'approccio "elenco piatto" in cui è necessario implementare il "salto" nel ciclo che applica le condizioni.

È sufficiente impostare la catena di condizioni:

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

E inizia la valutazione con una semplice chiamata:

c1.alertOrPropagate(display);

Prima di tutto, il codice originale non è terribile IMO. È abbastanza comprensibile e non c'è nulla di intrinsecamente cattivo in esso.

Quindi, se non ti piace, basandoti sull'idea di @ Ewan di usare un elenco ma rimuovendo il suo foreach breakschema in qualche modo innaturale :

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()

Ora adatta questo nella tua lingua preferita, trasforma ogni elemento della lista in un oggetto, una tupla, qualunque cosa, e sei bravo.

EDIT: sembra che non sia così chiaro che ho pensato, quindi lasciami spiegare ulteriormente. conditionsè un elenco ordinato di qualche tipo; headè l'elemento corrente che si sta studiando - all'inizio è il primo elemento dell'elenco e ogni volta che next()viene chiamato diventa il seguente; check()e alert()sono il checkConditionX()e addAlert(X)dal PO.

La domanda manca di alcuni dettagli. Se le condizioni sono:

• soggetto a modifiche o
• ripetuto in altre parti dell'applicazione o del sistema o
• modificato in alcuni casi (come build, test, distribuzioni diverse)

o se il contenuto in addAlertè più complicato, allora una soluzione forse migliore in dire che c # sarebbe:

//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)

Le tuple non sono così belle in c # <8, ma scelte per comodità.

I pro con questo metodo, anche se nessuna delle opzioni sopra indicate, è che la struttura è tipizzata staticamente. Non puoi rovinare accidentalmente, diciamo, perdere un else.

Il modo migliore per ridurre la complessità ciclomatica nei casi in cui si ha molto if->then statementsè utilizzare un dizionario o un elenco (dipendente dalla lingua) per memorizzare il valore chiave (se il valore dell'istruzione o un valore di) e quindi un risultato valore / funzione.

Ad esempio, anziché (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

Posso semplicemente

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];
}

Se stai usando linguaggi più moderni puoi archiviare più logica, quindi anche semplicemente valori (c #). Si tratta in realtà solo di funzioni incorporate, ma puoi anche puntare anche ad altre funzioni se la logica è troppo strana da mettere in linea.

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);
}

Sto cercando di seguire i suggerimenti sul codice pulito di zio Bob e in particolare di mantenere i metodi brevi.

Mi trovo incapace di abbreviare questa logica però:

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

Il tuo codice è già troppo breve, ma la logica stessa non dovrebbe essere modificata. A prima vista sembra che tu ti stia ripetendo con quattro chiamate checkCondition(), ed è evidente che ognuno è diverso dopo aver riletto il codice con attenzione. È necessario aggiungere la formattazione e i nomi delle funzioni corretti, ad esempio:

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);
}

Il tuo codice dovrebbe essere leggibile sopra ogni altra cosa. Dopo aver letto diversi libri di zio Bob, credo che sia il messaggio che sta costantemente cercando di trasmettere.

Supponendo che tutte le funzioni siano implementate nello stesso componente, è possibile fare in modo che le funzioni mantengano un certo stato al fine di sbarazzarsi dei molteplici rami nel flusso.

EG: checkCondition1()diventerebbe evaluateCondition1(), su cui verificherebbe se le condizioni precedenti fossero soddisfatte; in tal caso, memorizza nella cache un valore da recuperare getConditionNumber().

checkCondition2()diventerebbe evaluateCondition2(), su cui verificherebbe se le condizioni precedenti fossero soddisfatte. Se la condizione precedente non è stata soddisfatta, verifica lo scenario di condizione 2, memorizzando nella cache un valore da recuperare getConditionNumber(). E così via.

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

MODIFICARE:

Ecco come dovrebbe essere implementato il controllo delle condizioni costose per far funzionare questo approccio.

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;
}

Pertanto, se hai troppi controlli costosi da eseguire e le cose in questo codice rimangono private, questo approccio aiuta a mantenerlo, consentendo di modificare l'ordine dei controlli se necessario.

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

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

Questa risposta fornisce solo qualche suggerimento alternativo rispetto alle altre risposte e probabilmente non sarà migliore del codice originale se consideriamo solo 4 righe di codice. Sebbene, questo non sia un approccio terribile (e non rende neppure più difficile la manutenzione come altri hanno già detto) dato lo scenario che ho citato (troppi controlli, solo la funzione principale esposta come pubblica, tutte le funzioni sono dettagli di implementazione della stessa classe).

Non più di due clausole "else" costringono il lettore del codice a passare attraverso l'intera catena per trovare quella di interesse. Utilizzare un metodo come: void AlertUponCondition (Condition condition) {switch (condition) {case Condition.Con1: ... break; case condition.Con2: ... break; etc ...} Dove "Condition" è un enum corretto. Se necessario, restituisce un valore booleano o un valore. Chiamalo così: AlertOnCondition (GetCondition ());

In realtà non può essere più semplice, ed è più veloce della catena if-else una volta superati alcuni casi.

Non posso parlare per la tua situazione particolare perché il codice non è specifico, ma ...

codice del genere è spesso un odore per un modello OO carente. Hai davvero quattro tipi di cose, ognuna associata al proprio tipo di segnalatore, ma piuttosto che riconoscere queste entità e creare un'istanza di classe per ognuna, le tratti come una cosa e provi a rimediare in un secondo momento, in un momento in cui davvero devi sapere con cosa hai a che fare per procedere.

Il polimorfismo potrebbe averti adattato meglio.

Diffidare del codice con metodi lunghi contenenti costrutti if-then lunghi o complessi. Spesso vuoi un albero di classe lì con alcuni metodi virtuali.