La soppressione degli errori '@' è una tecnica valida per i test per una chiave di array facoltativa?

4

Rarst e stavo discutendo offline sull'uso di "% co_de" % 'operatore di soppressione degli errori in PHP, in particolare per testare l'esistenza delle chiavi di "facoltative" , vale a dire le chiavi di array che vengono utilizzate come switch qui e la loro mancanza di esistenza nell'array è funzionalmente equivalente all'array avente la chiave con un valore uguale a @ .

Ecco lo pseudo-codice per questo scenario:

 function do_something( $args = array() ) {
   if ( @$args['switch'] ) {
      // Do something with this switch
   }
   // continue on...
 }

vs. questo approccio:

 function do_something( $args = array() ) {
   if ( ! empty( $args['switch'] ) && $args['switch'] ) {
      // Do something with this switch
   }
   // continue on...
 }

Naturalmente nella maggior parte dei casi d'uso, gli errori di soppressione non sarebbero A Good Thing (tm) . Tuttavia in questo caso d'uso in cui un array viene passato con un elemento opzionale, mi sembra che sia in realtà una tecnica molto buona, ma potrei sbagliarmi e vorrei sentire le opinioni di altri sull'argomento prima di prendere una decisione.

So che ci sono presunti risultati di prestazioni per l'utilizzo del precedente approccio, ma mi piacerebbe sapere come si confrontano con l'alternativa e se i risultati delle prestazioni sono davvero importanti negli scenari del mondo reale?

P.S. Ho deciso di postare questo perché, dopo aver discusso offline con Rarst, ha chiesto una domanda più generale qui sui programmatori ma in realtà non fornisce un esempio dettagliato del caso d'uso specifico di cui discutevamo. E siccome sono abbastanza sicuro che vorrà usare le risposte fuori dal contesto su quell'altra domanda come giustificazione del perché sopra è "cattivo" ho deciso che avevo bisogno di ottenere opinioni su < em> questo caso d'uso specifico .

    
posta MikeSchinkel 17.11.2011 - 23:37
fonte

1 risposta

6

Prima , quando si parla di penalità relative al rendimento , non è possibile ottenere una risposta ragionevole a meno che non vi sia un contesto in cui deve accadere.

Per illustrare, è un ritardo di 100 ms per registrare un stackdump quando un programma termina accettabile? Più che probabile.

Lo stesso ritardo di 100 ms è accettabile in un ciclo continuo che viene eseguito ogni volta che si elabora un record da 100 milioni? Certo che no.

Secondo , come fa qualcuno a sapere che hai soppresso l'errore perché lo stai effettivamente utilizzando per il controllo del flusso logico invece di non conoscerlo meglio e solo per provare implementare 'non vedere il male'. Il codice di autocertificazione è migliore del bisogno di commenti espliciti per assicurare alle persone le tue intenzioni.

Terzo , come notato da Yannis nell'altra domanda , ti stai davvero preparando per il fallimento a causa del potenziale per conseguenze indesiderate .

Quindi, per il bene di quelle povere anime che devono mantenere il tuo codice in futuro, non farlo!

Dopotutto, cosa guadagni davvero ?

    
risposta data 18.11.2011 - 00:48
fonte

Leggi altre domande sui tag