In generale, hai ragione sull'anticipazione dei problemi. Tuttavia, tutto è buono con moderazione. Un controllo eccessivo e non necessario rende il codice difficile da scrivere, leggere e testare.
Durante i test delle applicazioni, dovresti rilevare molti errori che potresti analizzare e determinare se si adattano al tuo piano di gestione degli errori (vedi sotto per i dettagli).
Se lavori in un team, il team dovrebbe comunicare questo piano in modo che il codice sia costruito in modo coerente.
Classifico i risultati dell'esecuzione di un pezzo di codice in base alla loro natura usando la frase: "il buono, il brutto e il cattivo".
Il buono è la tua normale elaborazione. Questo è quando il metodo esegue il caso dolce.
La categoria non valida è quando il metodo non può eseguire il proprio lavoro perché i dati trasmessi sono scadenti o insufficienti. Catturare questo tipo di errori è importante poiché questi potrebbero derivare dai controlli intenzionali.
Ad esempio, è possibile verificare la validità degli argomenti passati a un metodo prima di elaborarli, poiché un altro esempio è quando si richiede un metodo per l'aggiunta di un cliente ma non si fornisce un nome per tale cliente.
Un altro tipo di regole che rientrano in questa categoria riguarda l'overflow aritmetico e i valori nulli. Questi sono leggermente diversi rispetto alla normale convalida dei dati dell'utente. Ad esempio, un'equazione complessa può comportare un numero elevato che non si è sicuri se si adatti al tipo di dati di destinazione. Tali problemi dovrebbero valere la pena di codificare solo se in dubbio. Alla fine del test, tali controlli potrebbero non essere necessari.
La brutta categoria è quando il problema è al di fuori del tuo codice. Questo è un errore nel sistema, nella logica o in qualsiasi altra cosa. Ad esempio, in Aggiungi cliente, se durante l'inserimento, il database si riempie. Questo non è colpa del tuo programma o della tua logica. È necessario identificare, registrare e rilevare tali errori, ma solo in modo generico. Un approccio comune per questo è la clausola Catch (non sono sicuro di come PHP lo fornisce).
Se segui la suddetta classificazione dei tipi di errori, non dovrai controllare ogni affermazione.
Inoltre, dovresti creare il tuo codice tenendo presente quanto sopra. Quindi, non convalidare le regole aziendali nel mezzo dell'elaborazione I / O. I concetti di programmazione strutturata aiutano qui. Per ottenere un codice più pulito, potresti voler separare i metodi per la convalida dei dati dall'elaborazione I / O.
In linguaggi come Java e .Net, i linguaggi consentono di far esplodere le eccezioni, se lo consente PHP, questo ridurrà notevolmente la necessità di verifiche dettagliate poiché le tue azioni possono essere protette dagli errori quando inserisci il tuo codice all'interno del Prova l'ambito del blocco.
Un'altra regola importante è evitare di ripetere la codifica delle regole a diversi livelli quando è possibile. Ad esempio, lascia il Rif. Controlli di integrità (RI) e vincoli di database al database e non ripeterli nel codice. Ho visto sviluppatori che codificano l'eliminazione manualmente anche se il Database lo sta facendo per loro.
Il modo in cui definisci le tue interfacce di metodo influisce sulla tua capacità di controllare i risultati in maniera significativa. A volte le persone non restituiscono nemmeno i tipi primitivi e utilizzano le classi come modo per comunicare un feedback dettagliato dalle chiamate ai metodi.