¿Por qué debería corregir los errores de E_NOTICE? Pros y contras

¿Debo usar E_NOTICE habilitado en el servidor en vivo?

Como puedo ver en ¿Por qué debería corregir los errores de E_NOTICE? todos están de nuevo con el uso de isset() para omitir avisos. He leído pros, pero ¿qué hay de la legibilidad del código?

Examinemos algunos códigos:

 if ($this->_oldattributes['category_id'] != $tattr['category_id'] || $this->_oldattributes['deal_id'] != $tattr['deal_id'] ) { 

Claro para entender lo que quiero aquí, ¿verdad?

Vamos a agregar isset() para omitir avisos:

 $old_cat_id = isset($this->_oldattributes['category_id']) ? $this->_oldattributes['category_id'] : null; $new_cat_id = isset($tattr['category_id']) ? $tattr['category_id'] : null; $old_deal_id = isset($this->_oldattributes['deal_id']) ? $this->_oldattributes['deal_id'] : null; $new_deal_id = isset($tattr['deal_id']) ? $tattr['deal_id'] : null; if ($old_cat_id != $new_cat_id || $old_deal_id != $new_deal_id) { 

No está mal, pero ahora necesito más tiempo para entender lo que está sucediendo aquí.

Algunos bits sobre la depuración: nunca perdí un día para depurar los errores causados ​​por la variable no inicializada. Sí, tal vez se perdió la mitad de una hora para deslizarse hacia abajo en las clases / funciones, pero esto no es un gran desperdicio cuando se compara con la pérdida de legibilidad del código en mi humilde opinión.

Algunos detalles sobre el rendimiento: http://seanmonstar.com/post/909029460/php-error-suppression-performance

La diferencia fue que la supresión de la notificación tomó 100% mientras se comprobó si existía primero “Se realizó una prueba en 1000000 supresiones. ¿Cuántas de ellas aparecen en su código, incluso si usa Zend + Doctrine + alguna otra cosa? ¿Cuánto tiempo toma en comparación con las conexiones de DB, etc.?

Quizás no solía escribir el código correcto (solo usé PHP por mucho tiempo).

Para el contexto, hemos movido nuestro proyecto al servidor que muestra E_NOTICEs, es por eso que estoy preguntando esto. No sé por qué este es un gran problema para apagarlos?

Otro ejemplo:

 class Item extends CActiveRecord { private $_oldattributes = array(); public function afterFind() { // Save old values $this->_oldattributes = $this->getAttributes(); $this->_oldcategory = $this->category; $this->_olddeal = $this->deal; } 

entonces tendré nulo si los atributos antiguos no existen y:

 $tattr = $this->getAttributes(); $this->_oldattributes['category_id'] != $tattr['category_id'] 

que me dará lo que necesito y no hay errores, ¿verdad?

Lo mismo con un error no objeto, en Yii cuando he configurado relaciones algunos objetos pueden no inicializarse, sí hay un tipo de error, porque tener valor nulo y no inicializado en este caso es un error real a veces:

 $this->deal->item->id != $this->_olddeal->item->id 

Esto puede desencadenar un aviso pero funcionará según lo previsto, por lo que ignora el aviso:

 if ($_GET['foo']) ... 

El problema es que no puedo ignorar esto, porque todavía lo noto y cada vez que uso esto debo escribir:

 if (isset($_GET['foo']) && $_GET['foo']) ... 

o:

 if (@$_GET['foo']) ... 

Cuando miro tu código, por ejemplo

 $this->_oldattributes['category_id'] 

Lo primero que pensé fue que probablemente debería ser una clase.

 class Attributes { public $categoryId; // and so on } 

La diferencia ahora es que ya no es necesario usar isset() , porque ahora la propiedad existe (tal vez es null ) o definitivamente es un error (“propiedad no definida”) y debe corregirse. Creo que la mayoría de tus casos, que ” isset() ” con isset() , son de este tipo.

Al depurar el código, es bueno tener mensajes variables indefinidos cuando las variables que se deben definir no están definidas. Creo que es una buena práctica definir tus variables antes de su uso, por lo que sé que otros lenguajes son más estrictos en esto que PHP.