Complessità ciclica durante la protezione dell'input

Stai eseguendo test identici su due set di valori indipendenti. Calcola una funzione che esegue quei test su un singolo set di valori, quindi chiama due volte:

int DateInvalid (int d, int m, int y)
{
     return y < 2000 ||
         !(m >= 1 && m <= 12) ||
         !(d >= 1 && d <= DaysInMonth(m)) ||
         (m == 2 && IsLeap(y) && !(d >= 1 && d <= DaysInMonth(m) + 1));
}

...
if (DateInvalid (d1, m1, y1) || DateInvalid (d2, m2, y2)) return 0;

O, meglio ancora, usa un'implementazione di calendario esistente per eseguire il controllo, eliminando così la necessità di avere un codice di manipolazione delle date (che è notoriamente facile da sbagliare).

Escludiamo la negazione eccessiva, il che rende la logica molto più difficile da leggere.

Gli stessi test possono essere scritti usando solo la disgiunzione anziché come disgiunzione delle congiunzioni negate.

return y < 2000 ||
     m < 1 || m > 12 ||
     d < 1 || d > DaysInMonth(m,y);

dove

int DaysInMonth(m,y) {
    return DaysInNonLeapYearMonth(m) + (m == 2 && IsLeap(y) ? 0 : 1);
}

La versione disgiuntiva è quasi leggibile rispetto alle congiunzioni negate.

Come già detto, l'utilizzo delle utilità di data esistenti è migliore. Supponiamo che non siano disponibili così posso presentare i seguenti suggerimenti.

Non utilizzare condizioni negate. IsDateValid è più facile da capire rispetto al contrario, specialmente se combinato con negazioni aggiuntive.

Considera di utilizzare il test del modulo a <= b && b <=c in quanto spesso leggono più facilmente, proprio come fa a ≤ b ≤ c .

Prova a trovare un modulo che non richiede parentesi e nessuna negazione aggiuntiva come

boolean isDateValid(int d, int m, int y) {
     return 2000 <= y 
         && 1 <= m && m <= 12
         && 1 <= d && d <= daysInMonth(m, y);
}

Ridurre la complessità ciclomatica non dovrebbe essere il tuo obiettivo principale in questo scenario. La convalida sembra essere una sorta di "se viene rilevato qualcosa di negativo, restituisce false, altrimenti restituisce true". Questi tipi di convalida sono solitamente abbastanza facili da capire, indipendentemente da ciò che riporta lo strumento di analisi.

In questi scenari, a meno che parti dei test di convalida siano usati in altre aree, è ok avere una funzione lunga / complessa.

Soprattutto in questo scenario, poiché la gestione di data e ora è una di quelle zone odiosamente sfumate e difficili da ottenere. Il tuo obiettivo dovrebbe essere la correttezza e utilizzare librerie di data / ora affidabili e consolidate è il modo per farlo.

Come praticamente tutte le "regole" nello sviluppo del software, ci sono delle eccezioni a ogni regola. Mentre la complessità ciclomatica solitamente indica che una funzione sta diventando troppo grande per essere facilmente compresa, a volte non è così. Questo potrebbe essere uno di questi.

La tua complessità ciclomatica è così alta che il tuo codice non funziona. Rifiuterà il 29 febbraio negli anni bisestili, perché in primo luogo verifichi che la data sia entro i 28 giorni normali e fallisce.

Il problema immediatamente ovvio è che hai una funzione chiamata DaysInMonth con un solo parametro. È una bugia. Non restituisce il numero di giorni nel mese, restituisce un numero che a volte è corretto e talvolta non lo è. Una funzione denominata DaysInMonth deve avere due parametri, uno per il mese e uno per l'anno.

Per esperienza, una volta che vedi una bandiera rossa ovvia come questa, devi solo sapere che c'è un bug nelle vicinanze, ed era giusto. Il tuo codice non è necessario complesso perché non passi l'anno a DaysInMonth, e di conseguenza è sbagliato.

Renderai anche il tuo codice molto più leggibile (rimuovi le torsioni del cervello!) verificando una data valida.