php - remove - strip_tags wordpress
¿Por qué debería corregir los errores de E_NOTICE? (5)
Como desarrollador, trabajo con E_NOTICE encendido. Recientemente, me preguntaron por qué los errores E_NOTICE deberían ser corregidos. La única razón por la que pude pensar es que es una buena práctica corregir esos problemas.
¿Alguien más tiene alguna razón para justificar el tiempo / costo adicional gastado para corregir estos problemas?
Más específicamente, ¿por qué un gerente debería gastar el dinero para arreglarlo si el código ya funciona?
A menudo son indicativos de errores de lógica o errores tipográficos. Lo ayudarán a detectar situaciones en las que ha escrito mal un nombre de variable o está tratando de usar una variable antes de que se establezca.
También he visto argumentos de que es más eficiente evitar errores
Ben, creo que esta es una excelente pregunta. Es cierto que es una buena práctica seguir para intentar corregir cualquier error, incluso los no fatales, a menos que hacerlo impida la funcionalidad diseñada (y, por lo tanto, deseada) del sistema. Además, cualquier nivel de error indica que:
a) Hay algo mal con su código, o, b) Usted ha escrito un código que está en desuso, o ha escrito un código que de otra manera es inestable y por lo tanto propenso a los efectos secundarios.
Por lo tanto, creo que si el cronograma y el presupuesto de un proyecto le permiten hacerlo, siempre debe esforzarse por corregir tantos errores como sea posible, incluso si son menores en términos de su impacto en el producto final.
Por supuesto, hay un cierto nivel de aceptación del riesgo involucrado en el análisis de costo-beneficio, por lo que bien podría ser el caso de que los gerentes que supervisan el resultado del proyecto estén dispuestos a cubrir el costo futuro potencial de solucionar un problema conocido contra el el tiempo presente y el ahorro de costos asociados con no corregir un error. La matemática básicamente funciona de la manera que crees que sería: si el VP del costo de reparar el error en el futuro es menor que el dinero ahorrado hoy al no corregir el error, entonces no debes arreglarlo. Por otro lado, si el VP del costo de corregir el error en el futuro es mayor que el dinero ahorrado hoy al no solucionarlo, entonces debe solucionarlo hoy.
Eso, realmente, es la justificación para (o contra) reparar un error hoy, independientemente del nivel de error.
Este tipo de errores son una buena práctica para corregir, ya que son lo que llamamos "olor a código", sugieren otro problema (como nombres de variables mal escritos o uso de variables indefinidas / uso incorrecto de métodos), o probablemente causarán errores en el camino cuando reflejas / expandes el sistema.
Por supuesto, lo que dije aquí no es cierto en el 100% de los casos.
Porque un E_NOTICE indica un error .
PHP es demasiado tolerante para llamarlo así.
Por ejemplo, acceder a una variable indefinida produce un E_NOTICE .
Si esto sucede a menudo, por ejemplo, porque no está inicializando sus variables correctamente, y su aplicación está lanzando avisos por todos lados, ¿cómo va a diferenciar entre una "variable que funciona bien sin inicializar" y momentos en los que ¿Realmente has engordado un nombre variable?
Esto puede desencadenar un aviso, pero funcionará según lo previsto, por lo que ignorará el aviso:
if ($_GET[''foo'']) ...
Esto, por otro lado, perderá la mitad de su día mientras ignora el aviso y está tratando de descubrir por qué su función " bar() " no funciona:
$foo = bar();
if ($too) ...
Si no "corrige" el primer caso, donde la variable puede no existir legítimamente, no puede usar avisos significativos para detectar el error tipográfico en el segundo caso.
Los avisos están ahí para ayudarlo a depurar su aplicación. Si los ignoras, solo estás haciendo tu propia vida más difícil.
RESUMEN
Los documentos de configuración de PHP Runtime le dan una idea de por qué:
Habilitar E_NOTICE durante el desarrollo tiene algunos beneficios.
Para fines de depuración: los mensajes de AVISO le advertirán sobre posibles errores en su código. Por ejemplo, se advierte el uso de valores no asignados. Es extremadamente útil encontrar errores tipográficos y ahorrar tiempo para la depuración.
Los mensajes de AVISO le advertirán sobre el mal estilo. Por ejemplo, $ arr [item] es mejor escribir como $ arr [''item''] ya que PHP trata de tratar el "artículo" como constante. Si no es una constante, PHP supone que es un índice de cadena para la matriz.
Aquí hay una explicación más detallada de cada ...
1. PARA DETECTAR TYPOS
La causa principal de los errores E_NOTICE es errores tipográficos.
Ejemplo - notice.php
<?php
$username = ''joe''; // in real life this would be from $_SESSION
// and then much further down in the code...
if ($usernmae) { // typo, $usernmae expands to null
echo "Logged in";
}
else {
echo "Please log in...";
}
?>
Salida sin E_NOTICE
Please log in...
¡Incorrecto! ¡No quisiste decir eso!
Salida con E_NOTICE
Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...
En PHP, una variable que no existe devolverá un valor nulo en lugar de causar un error, y eso podría causar que el código se comporte de manera diferente a lo esperado, por lo que es mejor prestar atención a las advertencias E_NOTICE .
2. PARA DETECTAR LOS ÍNDICES DE ARCHIVOS AMBIGUOS
También le advierte sobre los índices de matriz que pueden cambiar en usted, por ejemplo
Ejemplo: el código se ve así hoy
<?php
$arr = array();
$arr[''username''] = ''fred'';
// then further down
echo $arr[username];
?>
Salida sin E_NOTICE
fred
Ejemplo: mañana incluirá una biblioteca
<?php
// tomorrow someone adds this
include_once(''somelib.php'');
$arr = array();
$arr[''username''] = ''fred'';
// then further down
echo $arr[username];
?>
y la biblioteca hace algo como esto:
<?php
define("username", "Mary");
?>
Nueva salida
Vacío, porque ahora se expande a:
echo $arr["Mary"];
y no hay una clave Mary en $arr .
Salida con E_NOTICE
Si solo el programador tuviera E_NOTICE , PHP habría impreso un mensaje de error:
Notice: Use of undefined constant username - assumed ''username'' in /home/user/example2.php on line 8
fred
3. LA MEJOR RAZÓN
Si no arregla todos los errores E_NOTICE que cree que no son errores, probablemente se vuelva complaciente y empiece a ignorar los mensajes, y un día, cuando ocurra un error real, no lo notará.