Un'espressione booleana più grande è più leggibile della stessa espressione suddivisa in metodi predicati? [chiuso]

Cosa è più facile da capire, una grande dichiarazione booleana (abbastanza complessa) o la stessa istruzione suddivisa in metodi predicati (molto codice extra da leggere)?

Opzione 1, la grande espressione booleana:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {

        return propVal.PropertyId == context.Definition.Id
            && !repo.ParentId.HasValue || repo.ParentId == propVal.ParentId
            && ((propVal.SecondaryFilter.HasValue && context.SecondaryFilter.HasValue && propVal.SecondaryFilter.Value == context.SecondaryFilter) || (!context.SecondaryFilter.HasValue && !propVal.SecondaryFilter.HasValue));
    }

Opzione 2, Le condizioni suddivise in metodi predicati:

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {
        return MatchesDefinitionId(context, propVal)
            && MatchesParentId(propVal)
            && (MatchedSecondaryFilter(context, propVal) || HasNoSecondaryFilter(context, propVal));
    }

    private static bool HasNoSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);
    }

    private static bool MatchedSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    }

    private bool MatchesParentId(TValToMatch propVal)
    {
        return (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    }

    private static bool MatchesDefinitionId(CurrentSearchContext context, TValToMatch propVal)
    {
        return propVal.PropertyId == context.Definition.Id;
    }

Preferisco il secondo approccio, perché vedo i nomi dei metodi come commenti, ma capisco che è problematico perché devi leggere tutti i metodi per capire cosa fa il codice, quindi astraggono le intenzioni del codice.

Cosa è più facile da capire

Quest'ultimo approccio. Non è solo più facile da capire, ma è anche più facile da scrivere, testare, riformattare ed estendere. Ogni condizione richiesta può essere tranquillamente disaccoppiata e gestita a modo suo.

è problematico perché devi leggere tutti i metodi per capire il codice

Non è problematico se i metodi sono nominati correttamente. In effetti sarebbe più facile da capire poiché il nome del metodo descriverà l'intento della condizione.
Per uno spettatore if MatchesDefinitionId()è più esplicativo diif (propVal.PropertyId == context.Definition.Id)

[Personalmente, il primo approccio mi fa male agli occhi.]

Se questo è l'unico posto in cui verranno utilizzate queste funzioni di predicato, puoi anche utilizzare le boolvariabili locali :

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    bool matchesDefinitionId = (propVal.PropertyId == context.Definition.Id);
    bool matchesParentId = (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    bool matchesSecondaryFilter = (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    bool hasNoSecondaryFilter = (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);

    return matchesDefinitionId
        && matchesParentId
        && matchesSecondaryFilter || hasNoSecondaryFilter;
}

Questi potrebbero anche essere suddivisi ulteriormente e riordinati per renderli più leggibili, ad esempio con

bool hasSecondaryFilter = propVal.SecondaryFilter.HasValue;

e quindi sostituendo tutte le istanze di propVal.SecondaryFilter.HasValue. Una cosa che sporge immediatamente è che hasNoSecondaryFilterutilizza AND logico sulle HasValueproprietà negate , mentre matchesSecondaryFilterutilizza un AND logico su non negato HasValue, quindi non è esattamente l'opposto.

In generale, è preferito quest'ultimo.

Rende il sito di chiamata più riutilizzabile. Supporta DRY (il che significa che hai meno posti per cambiare quando cambiano i criteri e puoi farlo in modo più affidabile). E molto spesso questi sottocriteri sono cose che verranno riutilizzate indipendentemente altrove, permettendoti di farlo.

Oh, e rende queste cose molto più facili da testare, dandoti la sicurezza di averlo fatto correttamente.

Se è tra queste due scelte, quest'ultima è migliore. Queste non sono le uniche scelte, comunque! Che ne dici di suddividere la singola funzione in più if? Prova i modi per uscire dalla funzione per evitare ulteriori test, emulando approssimativamente un "cortocircuito" in un test a linea singola.

È più facile da leggere (potrebbe essere necessario ricontrollare la logica del tuo esempio, ma il concetto è valido):

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    if( propVal.PropertyId != context.Definition.Id ) return false;

    if( repo.ParentId.HasValue || repo.ParentId != propVal.ParentId ) return false;

    if( propVal.SecondaryFilter.HasValue && 
        context.SecondaryFilter.HasValue && 
        propVal.SecondaryFilter.Value == context.SecondaryFilter ) return true;

    if( !context.SecondaryFilter.HasValue && 
        !propVal.SecondaryFilter.HasValue) return true;

    return false;   
}

Mi piace l'opzione 2 meglio, ma suggerirei un cambiamento strutturale. Combina i due controlli sull'ultima riga del condizionale in un'unica chiamata.

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    return MatchesDefinitionId(context, propVal)
        && MatchesParentId(propVal)
        && MatchesSecondaryFilterIfPresent(context, propVal);
}

private static bool MatchesSecondaryFilterIfPresent(CurrentSearchContext context, 
                                                    TValToMatch propVal)
{
    return MatchedSecondaryFilter(context, propVal) 
               || HasNoSecondaryFilter(context, propVal);
}

Il motivo per cui suggerisco questo è che i due controlli sono una singola unità funzionale e la nidificazione tra parentesi in un condizionale è soggetta a errori: sia dal punto di vista della scrittura iniziale del codice sia dal punto di vista della persona che lo legge. Questo è particolarmente vero se gli elementi secondari dell'espressione non seguono lo stesso modello.

Non sono sicuro che MatchesSecondaryFilterIfPresent()sia il nome migliore per la combinazione; ma non viene subito in mente niente di meglio.

Sebbene in C #, il codice non sia molto orientato agli oggetti. Sta usando metodi statici e quelli che sembrano campi statici (ad es repo.). Si ritiene generalmente che la statica renda difficile il refactoring del codice e difficile da testare, ostacolando al contempo la riusabilità e, alla tua domanda: un utilizzo statico come questo è meno leggibile e mantenibile della costruzione orientata agli oggetti.

È necessario convertire questo codice in una forma più orientata agli oggetti. Quando lo fai, scoprirai che ci sono posti ragionevoli per mettere il codice che fa il confronto di oggetti, campi, ecc. È probabile che potresti quindi chiedere agli oggetti di confrontarsi, il che ridurrebbe la tua grande istruzione if in un semplice richiesta di confronto (ad esempio if ( a.compareTo (b) ) { }, che potrebbe includere tutti i confronti tra campi.)

C # ha un ricco set di interfacce e utility di sistema per fare confronti su oggetti e loro campi. Al di là della ovvia .Equalsmetodo, per cominciare, guardare in IEqualityComparer, IEquatablee le utility come System.Collections.Generic.EqualityComparer.Default.

Quest'ultimo è sicuramente preferito, ho visto casi con il primo modo ed è quasi sempre impossibile da leggere. Ho commesso l'errore di farlo nel primo modo e mi è stato chiesto di cambiarlo in metodi predicati.

Direi che i due sono più o meno gli stessi, SE aggiungi uno spazio bianco per la leggibilità e alcuni commenti per aiutare il lettore nelle parti più oscure.

Ricorda: un buon commento dice al lettore cosa stavi pensando quando hai scritto il codice.

Con modifiche come ho suggerito, probabilmente andrei con il primo approccio, poiché è meno ingombrante e diffuso. Le chiamate di subroutine sono come note a piè di pagina: forniscono informazioni utili ma interrompono il flusso di lettura. Se i predicati fossero più complessi, li suddividerei in metodi separati in modo che i concetti che rappresentano possano essere costruiti in blocchi comprensibili.

Bene, se ci sono parti che potresti voler riutilizzare, separarle in funzioni separate con nome appropriato è ovviamente la migliore idea.
Anche se potresti non riutilizzarli mai, farlo potrebbe permetterti di strutturare meglio le tue condizioni e dare loro un'etichetta che descriva cosa significano .

Ora, diamo un'occhiata alla tua prima opzione, e ammettiamo che né il tuo rientro e l'interruzione di linea sono stati così utili, né il condizionale è stato strutturato così bene:

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) {
    return propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue
        || repo.ParentId == propVal.ParentId
        && propVal.SecondaryFilter.HasValue == context.SecondaryFilter.HasValue
        && (!propVal.SecondaryFilter.HasValue || propVal.SecondaryFilter.Value == context.SecondaryFilter.Value);
}

Il primo è assolutamente orribile. Hai utilizzato || per due cose sulla stessa linea; questo è un bug nel tuo codice o un intento di offuscare il tuo codice.

    return (   (   propVal.PropertyId == context.Definition.Id
                && !repo.ParentId.HasValue)
            || (   repo.ParentId == propVal.ParentId
                && (   (   propVal.SecondaryFilter.HasValue
                        && context.SecondaryFilter.HasValue 
                        && propVal.SecondaryFilter.Value == context.SecondaryFilter)
                    || (   !context.SecondaryFilter.HasValue
                        && !propVal.SecondaryFilter.HasValue))));

Questo è almeno a metà decentemente formattato (se la formattazione è complicata, è perché la condizione if è complicata) e hai almeno la possibilità di capire se qualcosa dentro non ha senso. Rispetto alla tua immondizia formattata se, qualcos'altro è meglio. Ma sembra che tu sia in grado di fare solo estremi: o un pasticcio completo di un'istruzione if o quattro metodi completamente inutili.

Si noti che (cond1 && cond2) || (! cond1 && cond3) può essere scritto come

cond1 ? cond2 : cond3

che ridurrebbe il disordine. Scriverei

if (propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue) {
    return true;
} else if (repo.ParentId != propVal.ParentId) {
    return false;
} else if (propVal.SecondaryFilter.HasValue) {
    return (   context.SecondaryFilter.HasValue
            && propVal.SecondaryFilter.Value == context.SecondaryFilter); 
} else {
    return !context.SecondaryFilter.HasValue;
}

Non mi piace nessuna di queste soluzioni, sono entrambe difficili da ragionare e difficili da leggere. L'astrazione con metodi più piccoli solo per motivi di metodi più piccoli non risolve sempre il problema.

Idealmente, penso che dovresti confrontare metaprogrmaticamente le proprietà, quindi non hai un nuovo metodo definito o se ramo ogni volta che vuoi confrontare un nuovo set di proprietà.

Non sono sicuro di c #, ma in JavaScript qualcosa del genere sarebbe MOLTO migliore e potrebbe almeno sostituire MatchesDefinitionId e MatchesParentId

function compareContextProp(obj, property, value){
  if(obj[property])
    return obj[property] == value
  return false
}