2011-09-20 17 views
7

Sono abituato a controllare il tipo dei miei parametri durante la scrittura delle funzioni. C'è una ragione a favore o contro questo? Ad esempio, sarebbe una buona pratica mantenere la verifica della stringa in questo codice o rimuoverla, e perché?Dovresti verificare i tipi di parametri nelle funzioni PHP?

function rmstr($string, $remove) { 
    if (is_string($string) && is_string($remove)) { 
     return str_replace($remove, '', $string); 
    } 
    return ''; 
} 

rmstr('some text', 'text'); 

Ci sono momenti in cui ci si può aspettare diversi tipi di parametri ed eseguire codice diverso per loro, nel qual caso la verifica è essenziale, ma la mia domanda è se si debba esplicitamente verificare la presenza di un tipo e di evitare un errore.

+8

È eccessivo a meno che non si stia effettuando una libreria API o la gestione dell'input dell'utente. – thedaian

+0

Ho pensato che ci sarebbe stato un graduale decadimento delle prestazioni se tutte le funzioni che hai scritto l'hanno fatto, specialmente se si tratta di funzioni interne/private che solo tu chiami. –

+0

Suppongo che dipenda da cosa succederebbe se non avessi il tuo test e fallisse. – Steve

risposta

5

La mia opinione è che si dovrebbe eseguire tale verifica se si accettano input da parte dell'utente. Se quelle stringhe non sono state accettate dall'utente o sono state disinfettate dall'utente, allora fare la verifica è eccessivo.

+0

Sono d'accordo con te, sono una di quelle persone che controlla ogni volta (ho sempre paura degli errori). Ma normalmente questo porta al caos. Suggerisco di limitare anche i tuoi assegni, davvero. –

+2

Per farti sapere, tutti i dati provenienti dall'utente hanno l'unico tipo - stringa. Quindi, il tipo di controllo diventa completamente ** inutile ** –

+0

Questo è un buon punto @ Col.Shrapnel, immagino che faccia in modo che i tipi di verifica dall'input dell'utente siano un po 'ridondanti, a meno che non ci si aspetti che gli utenti della funzione lo chiamino direttamente nel loro codice piuttosto che è passato da una forma. –

6

Sì, va bene. Tuttavia, php non è fortemente digitato per cominciare, quindi penso che questo non sia molto utile nella pratica.

Inoltre, se si utilizza un oggetto diverso dalla stringa, un'eccezione è più informativa; quindi, proverei a evitare di restituire una stringa vuota alla fine, perché non spiega semanticamente che chiamare rmstr (array, object) restituisce una stringa vuota.

+0

Sì, di solito utilizzo FALSE di ritorno laddove possibile per evitare il sovraccarico di un'eccezione in una funzione così piccola, ma qui ho assunto che l'utente si aspetterebbe una stringa da rmstr indipendentemente dal loro input. –

+0

@Aram niente di sbagliato nel restituire anche FALSE. Sarà convertito anche in vuoto –

1

Sembra che la gente locale abbia compreso questa domanda come "Dovresti verificare i parametri" dove era "Dovresti verificare il parametro tipi", e fatto delle risposte senza senso e dei commenti fuori da esso.

Personalmente non sto mai controllando i tipi di operandi e non ho mai avuto problemi.

2

Per quanto mi riguarda, digita il controllo effettivo sui dati, generato dall'utente al livello principale dell'astrazione, ma successivamente, quando chiami la maggior parte delle tue funzioni, dovresti già il loro tipo e non verificarlo in ogni metodo. Influisce sulle prestazioni e sulla leggibilità.

Nota: è possibile aggiungere informazioni, quali tipi è permesso di argomenti per le funzioni da PHPDoc

0

Dipende quale codice si producono. Se è in realtà un codice di produzione, è necessario assicurarsi che la funzione funzioni correttamente in qualsiasi circostanza. Ciò include il controllo che i parametri contengano i dati che ti aspetti. Altrimenti lanciare un'eccezione o avere un'altra forma di gestione degli errori (che manca completamente nel tuo esempio).

Se non è destinato alla produzione e non è necessario codificare in modo difensivo, è possibile ignorare qualsiasi cosa e seguire il principio di spazzatura-in-spazzatura (o il principio di tre merda: codice merda, merda di processo, merda).

Alla fine si tratta di soddisfare le aspettative: se non è necessario che la funzione funzioni correttamente, non è necessario codificarla correttamente. Se si sta effettivamente facendo affidamento sul proprio codice per funzionare con precisione, è anche necessario convalidare i dati di input per ogni unità (funzione, classe).

Problemi correlati