Sarebbe meglio avere controlli extra, o sarebbe una perdita di tempo? [duplicare]

Cosa succede se:

• Alcune altre applicazioni manipolano la finestra e rendono visibile il pulsante mentre la musica non viene riprodotta?

• Un thread interrompe la musica e sta per nascondere il pulsante quando si controlla la visibilità di un pulsante?

• Qualche altro sviluppatore modifica il codice, senza conoscere la relazione tra la visibilità del pulsante e lo stato della musica?

• Hai modificato il codice da quando i requisiti sono stati modificati e invece di nascondere il pulsante, ti è stato necessario disabilitarlo solo?

• Sostituisci il pulsante con un altro controllo?

In altre parole:

1. Non dovresti controllare una condizione se "non esiste un modo possibile in cui sia vero / falso". Ad esempio il blocco if nel seguente codice è ridondante e dovrebbe essere rimosso:

   assert(input > 0);
   var i = input * 2;
   if (i > 0)
   {
       // Do something useful.
   }
   

2. Dovresti controllare una condizione in un caso come quello che hai illustrato, poiché non esiste una relazione rigida e affidabile tra la visibilità di un pulsante e lo stato della musica.

Nota che nel tuo codice, ciò che dovresti omettere è il primo if . Dato che vuoi semplicemente interrompere la musica (e per una ragione, non puoi chiamare music stopPlaying se la musica non è in riproduzione), l'unico controllo che dovresti fare è if ([music playing]) . Che il pulsante sia visibile o meno non ha importanza. Non ti importa se è visibile o meno, abilitato o meno, o anche se esiste.

Ad esempio qualcosa come:

if ([button visible])
    if ([music playing])
        [music stopPlaying]
        [button hide]

potrebbe essere riscritto come:

if ([music playing])
    [music stopPlaying]
    [button hide]

se la visibilità del pulsante dipende dallo stato della musica. L'associazione dei dati, se supportata dalla tua lingua / framework, è ancora migliore:

[button visibility=(bind:music state)]

// Later in code:

if ([music playing])
    [music stopPlaying] // The button is hidden automatically

Paragonerei questi controlli apparentemente superflui all'attivazione del tuo direzionale quando si accende una strada vuota.

Su quella strada vuota, hai svolto la dovuta diligenza, controllato i dintorni e controllato il tuo specchietto retrovisore. Non c'è nessuno intorno, quindi perché dovresti attivare il tuo direzionale?

Ecco perché: la prossima volta che guidi su una strada ugualmente vuota, potresti perdere un'auto nel punto cieco.

L'atto di attivare la direzione della tua auto comunica l'intento. Inoltre, è solo una buona abitudine.

Allo stesso modo, ti consiglio di includere tali verifiche nel tuo codice ovunque tu pensi che siano applicabili. Questi controlli comunicheranno l'intenzione ai futuri programmatori che leggeranno il tuo codice. E alla luce del fatto che il tuo codice verrà modificato in futuro, non puoi prevedere il contesto delle future chiamate di metodo.

EDIT: Per @Chuck Conway, è probabilmente meglio convertire la maggior parte di questi controlli if in istruzioni assert o if (not 'X') then throw . Un'istruzione incapsulatrice if potrebbe nascondere un bug inaspettato!

Inoltre, sono d'accordo con il suo punto sulla semplicità. C'è una linea sottile tra l'aggiunta di alcuni controlli aggiuntivi e l'aggiunta di spazzatura che confonderà i futuri programmatori. Quindi sii giudizioso.

In your opinion, do you think it is a waste of time to make checks that you know there is no possible way of it being there/not being there, or would you just put it there just in case there is a bug or something?

Ci sono tre possibilità, è implossabile

int i = 0;
if (i==1 && i==2) {
 // useless test
}

È possibile ma richiede una modifica del codice da qualche parte.

int i = 0;
if (i>0) {
// line above should prevent this from happening.
// extreme case, if this branch is executing someone did something wrong
}

E infine potrebbe semplicemente essere uno stato non valido, qualcosa che non pensate possa accadere dati dati buoni.

Il primo caso è una totale perdita di tempo, nessuna modifica al codice o l'input dell'utente può portare al test successivo. Il secondo caso è MOLTO inutile, ma una variazione su di esso può essere utile. Fondamentalmente, il secondo caso presentato richiede una modifica del codice per quel ramo da prendere, ma un esempio più complesso potrebbe essere utile per convalidare un'ipotesi che è inserita nel seguente algoritmo, ma non è intrinsecamente applicata.

Per esempio, se invece di un int, si stesse creando un utente non inizializzato, quindi un controllo che il nome fosse vuoto potrebbe teoricamente essere valido - l'utente potrebbe essere cambiato in modo che venga fornito un nome predefinito e se una scrittura una volta che la proprietà è stata modificata in modo che il nome predefinito possa essere cambiato, potrebbe rovinare tutto.

Ma in realtà, ci sono modi migliori per testare tali cose (unit test ad esempio, anche se non è proprio quello per cui sono).

Infine, c'è l'ultimo caso - e se lo provi dipende da cosa puoi fare al riguardo che è utile. E quanto sia improbabile che tu pensi che - se realisticamente non accadrà mai, allora provarlo per te è una perdita di tempo. Se d'altro canto, non dovrebbe accadere, ma può, quindi, prenderlo se puoi fare qualcosa di utile.