Dovremmo inserire casi speciali in business logic / algoritmi o lasciarli separati? [chiuso]

Question

Dovremmo inserire casi speciali in business logic / algoritmi o lasciarli separati? [chiuso]

#1 da (2 voti)
#2 da (0 voti)

-1

Considera che ho alcuni codici che utilizzano una logica diversa per alcuni casi speciali, ad esempio:

bool compareRatio(unsigned int a,unsigned int b,unsigned int x,unsigned int y){
    if(x==0){
        return false;
    }else if(y==0){
        return true;
    }else{
        return (float)a/x<(float)b/y;
    }
}

e per eliminare casi speciali, posso riscriverlo:

bool compareRatio(unsigned int a,unsigned int b,unsigned int x,unsigned int y){
    return a*y<b*x;
}

e per altre situazioni simili, come la ricerca in array con la dimensione dell'array case speciale = 0:

int[] a={1,4,2,7,5,1};
if(a.length == 0 ){
}else{
    for(int i=0;i<a.length;i++){
    }
}

Posso anche riscriverlo come:

int[] a={1,4,2,7,5,1};
for(int i=1;i<a.length;i++){
}

Ma la mia domanda è, dovremmo tendere ad eliminare casi speciali, o semplicemente lasciarli nel codice? O dipende dai casi? Penso che eliminare il caso speciale possa ridurre il numero di codici, ma i codici diventano meno diretti. In alternativa, lasciare casi speciali può rendere il codice brutto, ma penso che sia più facile da mantenere e possa ricordare ad altri programmatori che questa logica aziendale ha alcune condizioni speciali. Quale stile è preferito?

coding-style

posta ggrr 15.04.2016 - 10:36

fonte

2 risposte

Leggi altre domande sui tag coding-style

Il browser consente il cookie sicuro su http Come garantire la separazione e le dipendenze interne tra i livelli architetturali in Python?

score 2 · Answer 1

Il codice più semplice e corretto è quasi sempre il migliore. Documenta il comportamento previsto sia nei commenti che nei test unitari. Il tuo primo esempio non ha nemmeno casi speciali, e il semplice "return a * y < b * x" è decisamente preferibile all'alternativa. Quindi scrivi alcuni test unitari, uno con xey zero, uno con x zero, uno con y zero e tre casi in cui a / x < b / a, a / x = b / a, a / x > b / y.

score 0 · Answer 2

Di solito cerco di mantenere il codice leggibile (= semplice) il più possibile, quindi cerco di eliminare tali casi dove possibile.

Quindi la domanda è: quando è possibile? Hai sicuramente bisogno di quei controlli se fanno parte della logica di business (ad esempio un controllo di equilibrio prima di ridurre un conto bancario). Non lo fai se puoi fare delle ipotesi (+ documentale) sulle condizioni preliminari, ad es. Il parametro v non deve essere null .

Nel tuo primo esempio ti impedisci di lanciare un'eccezione a causa di una divisione di 0. Questo è buono, perché se un chiamante può fornire 0 probabilmente lo farà a un certo punto. Non avresti bisogno del controllo se fosse molto improbabile che nel tuo contesto / applicazione X diventi 0. Questo è un caso di gestione delle eccezioni.

Nel tuo secondo esempio, stai solo prendendo una scorciatoia. Entrambe le versioni si comporterebbero allo stesso modo. Quindi prendi quello, che è meglio leggibile / manutenibile.