Perché molti sviluppatori PHP odiano usare isset () e / o una qualsiasi delle funzioni difensive di PHP come empty ()?

Su stackoverflow, vedo che questo problema si ripresenta continuamente:

• E_NOTICE? == E_DEBUG, evitando isset () e @ con un gestore_errore più sofisticato
• Come impostare PHP per non controllare l'indice di non trovare $ _GET quando E_NOTICE è attivo?
• Come impedire a PHP di registrare errori di avviso PHP
• Come posso disattivare tali avvisi di PHP 5.3?

Perfino Pekka (che offre molti solidi consigli su PHP) si è scontrato con il E_NOTICEmostro temuto e sperava in una soluzione migliore rispetto all'utilizzo di isset(): isset () e empty () rendono il codice brutto

Personalmente, utilizzo isset()e empty()in molti luoghi per gestire il flusso delle mie applicazioni. Per esempio:

public function do_something($optional_parameter = NULL) {
    if (!empty($optional_parameter)) {
        // do optional stuff with the contents of $optional_parameter
    }
    // do mandatory stuff
}  

Anche un semplice frammento come questo:

if (!isset($_REQUEST['form_var'])) {
    // something's missing, do something about it.
}

mi sembra molto logico. Non sembra gonfio, sembra un codice stabile. Ma molti sviluppatori accendono le loro applicazioni con E_NOTICEle funzioni abilitate, scoprono molte frustranti comunicazioni "indice di array non inizializzate" e poi fanno una smorfia alla prospettiva di verificare le variabili definite e di "sporcare" il loro codice isset().

Presumo che altre lingue gestiscano le cose in modo diverso. Parlando per esperienza, JavaScript non è educato come PHP. Una variabile non definita in genere interrompe l'esecuzione dello script. Inoltre, (parlando per inesperienza ) sono sicuro che linguaggi come C / C ++ semplicemente rifiuterebbero di essere compilati.

Quindi, gli sviluppatori PHP sono semplicemente pigri? (non parlando di te, Pekka, so che stavi eseguendo il refactoring di una vecchia applicazione.) O altre lingue gestiscono le variabili indefinite in modo più grazioso rispetto al richiedere al programmatore di verificare prima se sono definite?

(So ​​che ci sono altri E_NOTICEmessaggi oltre alle variabili indefinite, ma quelli sembrano essere quelli che causano il maggior dispiacere)

Addendum
Dalle risposte finora, non sono il solo a pensare che isset()non sia un eccesso di codice. Quindi, mi chiedo ora, ci sono problemi con i programmatori in altre lingue che fanno eco a questo? O è solo un problema di cultura PHP?

Codifico E_STRICTe nient'altro.

L'uso di assegni vuoti e isset non rende il tuo codice brutto, ma rende il tuo codice più dettagliato. Nella mia mente qual è la cosa peggiore in assoluto che può accadere dal loro utilizzo? Scrivo qualche altro personaggio.

Versi sulle conseguenze del non usarli, per lo meno avvertimenti.

Penso che gli avvisi su elementi sconosciuti siano un errore di progettazione in PHP. Non sono sicuro che sia possibile correggere l'errore ora, ma produce un sacco di codice del bollettino come if(isset($foo['abc']) && $foo['abc'] == '123')- questo codice non dovrebbe avere isset, poiché l'intento è quello di verificare se c'è '123' in un determinato posto di $fooe se non c'è nulla lì è sicuramente non "123". L'unica ragione per cui devi scrivere il doppio del codice è a causa di questo sfortunato errore di progettazione in PHP. E , purtroppo, gli avvisi in PHP sono molto costosi, quindi disabilitarli non è un'opzione per il codice in cui le prestazioni sono un problema.

Quindi sì, rende il codice IMHO brutto e mi infastidisce. E non è per mancanza di esperienza: uso PHP dal 1998 e ricordo quando c'era l' .php3estensione e significava "non è PHP 2". Forse sono pigro :) Ma la pigrizia - almeno un certo tipo - è una virtù per un programmatore.

D'altra parte, l'uso valido di issete empty- proprio come quelli del post originale - va bene. Penso solo che PHP sia troppo zelante riguardo agli avvisi in luoghi in cui isset/emptynon sono realmente necessari.

Credo che PHP, come linguaggio gratuito, interpretato e utilizzato sul Web, abbia un'alta percentuale di programmatori non professionisti e non addestrati che non sono pienamente consapevoli del perché dovrebbero codificare in modo difensivo e vedono gli avvisi come un altro errore non necessario .

Ho sempre sentito questi punti da sviluppatori junior e programmatori di script autodidatta:

• Perché inizializzare una variabile se verrà comunque all'esistenza?
• Perché verificare se esiste qualcosa prima di usarlo, undefined equivale a false comunque?
• Se prefisso @ risolve il mio codice, perché complicare le cose?

Se non hanno mai sperimentato un linguaggio fortemente tipizzato o sperimentato le insidie ​​di variabili non dichiarate / non motivate, assumono alcune convinzioni. Trovo che di solito si arrendano dopo aver provato il piacere del debug del codice per circa un'ora per scoprire che era un errore di battitura in un nome di variabile che causava il problema.

L'altro fattore forte è l'uso di PHP nel settore web, che tende ad essere molto più interessato alla produttività che alla sicurezza e alla qualità del codice.

Sì, sono pigri. Molti comunque ...

Sfortunatamente la mentalità di molti programmatori di PHP è "Non ha senso codificare in modo difensivo se è possibile ottenere lo stesso risultato finale più rapidamente facendo affidamento sul linguaggio per gestire gli errori causati da variabili mancanti ecc. Ecc." Lo so, ho lavorato con molti di loro.

Tendono anche a essere quelli che misteriosamente si dirigono verso un pranzo presto quando la loro mancanza di una corretta gestione e segnalazione degli errori porta fuori i server live per diverse ore ...

Cerco di evitare l'uso di isset () e empty () evitando l'uso di array come oggetti di trasferimento dati. Creare una classe che può essere configurata per accettare un set limitato di proprietà con valori predefiniti sani e convalidare l'input per tali proprietà. Può persino implementare l'interfaccia ArrayAccess in modo da poterlo usare come un array. Ciò consente anche di utilizzare il suggerimento del tipo nelle firme del metodo per rilevare errori quando qualcuno tenta di passare il tipo di entità errato al metodo.

Una delle domande poste è la mia, quindi lasciatemi ripetere.

Molti sviluppatori confondono la presenza di molti isset()come segno di qualità. Dà un'apparenza di affidabilità e alcune persone la pensano anche come funzionalità di sicurezza.

Ma devi tenere conto del fatto che PHP non è un linguaggio compilato. È un linguaggio di scripting con un sistema di tipo dinamico. Gli errori E_NOTICE sono solo errori per nome. E se molti issetvengono utilizzati con la sola intenzione di sopprimere gli avvisi, in realtà stai solo codificando il linguaggio .

Quindi, gli sviluppatori PHP sono semplicemente pigri?

Questo è davvero il caso se vedi un'abbondanza di avvisi e avvertimenti lanciati. Molti neofiti non si preoccupano degli avvisi, ed è di solito il risultato di un completamente disabilitato error_reporting(0).

Ti sbagli però che altri sviluppatori non hanno riconosciuto E_NOTICE solo perché non erano @ o soppressi da isset. Almeno questa era la mia intenzione alla base delle domande sulle comunicazioni . Non sono qualcosa di cui sbarazzarsi, ma a volte importanti informazioni di debug.

Come tutte le generalizzazioni, l'uso sconsiderato di isset non porta a un codice ottimale. È importante differenziare dove issete emptysono necessari e dove sono sale sintattico .

O è solo un problema di cultura PHP?

No, gli "errori" variabili non definiti non sono solo un problema PHP. Bash, TCL e Perl o JavaScript consentono l'uso di variabili non definite. Questa caratteristica linguistica immanente non è vista come un difetto lì comunque. Esistono costrutti di linguaggio simili per verificare la presenza di valori non definiti. Tuttavia non sono usati costantemente come in PHP, a causa dei valori indefiniti che non sono stati definiti erroneamente come "errore".

Interessante. Non uso quasi mai isset (). Il mio codice PHP è raramente in uno stato in cui non so se una variabile è stata impostata in primo luogo. Ogni variabile GET o POST utilizzata è accessibile tramite una funzione che fornirà un valore predefinito se non esiste. I valori predefiniti nelle chiamate di funzione sono in genere impostati esplicitamente su 0 o stringhe vuote.

Uso isset e ne svuoto un sacco. Ma soprattutto sono i luoghi che menzioni, come l'elaborazione $ _REQUEST, nel caso in cui qualcuno abbia sbagliato i parametri. Nei casi in cui ho il controllo su tutte le variabili che volano in giro, trovo che di solito non ne ho bisogno.

Non mi piace usare isset, ma se ci sono masse di codice fatte da un altro, allora può essere una grazia salvifica. Ho scritto il seguente codice per aiutare con questo problema, invece di usare isset () isseter ($ a, $ b) restituirà $ b se $ a non è definito o vuoto, o la funzione restituisce un valore nullo. Eventuali miglioramenti, benvenuto:

//returns var or NULL (if undefined)
//$reserve optional second value is returned as $default if undefined
function isseter(&$default,&$reserve=NULL)
{
$default = isset($default) ? $default : NULL;
$reserve = isset($reserve) ? $reserve : NULL;
if ((!$default) && ($reserve)) $default=$reserve;
return $default;
}