Cada día veo que en este foro, no dejan de repetirse los post con errores básicos de PHP tales como sintaxis, asignación, etc.
Las preguntas se multiplican con comentarios tales como "no me funciona y no sé por qué", "no hace nada", "antes funcionaba y ahora no", "no he tocado nada", etc.
Para ver si es posible evitar todos estos post e idealmente para ver si se puede ayudar a alguien a escribir mejor código, os dejo una mini guía de debuging y tips para evitar errores básicos. El orden de los puntos no tiene realmente ninguna relación, todos son igualmente prioritarios. Asimismo, una explicación extensiva de cada punto no es posible en este documento. Esta no pretende ser la “Guía definitiva” así que espero que otros foreros se animen a extenderla y agradecemos de antemando a todos aquellos que la lean y la apliquen lo antes posible junto con las normas y consejos del foro para postear, saludos.
Algunas consideraciones:
A.
No hay manera de evitar los errores, pero se pueden minimizar y preveer siguiendo algunas líneas como las siguientes.
B. Para solucionar problemas con llamadas a funciones y classes propias del lenguage,
el manual de PHP es la mejor opción. Una simple mirada a la definición de las funciones sirve para conocer parámetros, tipos, resultados e incluso posibles bugs.
C. Para librerías de terceros
consulta siempre la documentación de los desarrolladores. Nadie mejor que ellos para saber cómo funciona, si no está debidamente documentada, busca soporte. Si no lo hay, plantéate la opción de sustituir ese software por otro.
D. Para API's tales como Google, Facebook, etc.,
busca en los foros especializados. Mucha gente antes que tú ha pasado por los mismos problemas. A su vez, muchos otros programadores jamás han tocado estas APIs y pierdes el tiempo en el sitio equivocado.
E. Aún cuando seas un aprendiz en el lenguage, copiar y pegar código “para salir del paso” no es una buena idea. Los posibles errores y bugs dentro de ese código te llevarán a nuevos y más complejos errores muy difíciles de detectar. Los que recurren al foro para buscar soluciones para el trabajo, la universidad, etc. deben saber que cualquier problema con el código obtenido saldrá a la luz tarde o temprano, y por lo general, estas cosas vuelven en el momento menos oportuno.
F. La utilización de Frameworks y librerías de terceros es definitivamente una opción a la hora de desarrollar y minimizar los errores pero cada caso se debe analizar individualmente.
G. Por último: NO HAY SUSTITUTO PARA EL CONOCIMIENTO Y LA EXPERIENCIA. HAY QUE ESTUDIAR, HAY QUE LEER, HAY QUE TRABAJAR porque como decían los chinos, "Es más fácil saber como se hace una cosa que hacerla."
------------------------------------------------------------------------ La Guía:
0. ERROR_REPORTING, en desarrollo, trabajar siempre con
Así se detectan TODOS los errores y se pueden solucionar el instante. No se debe seguir escribiendo código cuando existen variables indefinidas, índices no declarados, etc...
En producción, logear los errores en archivos pero no mostrarlos en el navegador.
Refactorea el código hasta que no quede ni un sólo mensaje del compilador.
Pregunta: para qué tengo que solucionar todos los errores si el programa funciona igual?? Para no “apilar” errores, para mantener la calidad y asegurar el funcionamiento actual y futuro. http://de3.php.net/manual/es/functio...-reporting.php 1. NO usar el operador @ para suprimir errores a no ser en circunstancias muy particulares (este tema se puede extender más adelante). Por norma, no hay que suprimir los errores generados en el código sino solucionarlos, esto nos lleva de nuevo a 0.
Pregunta: pero si quito la arroba el programa no funciona u obtengo mensajes de error, que hago??? Empieza a leer desde el punto 0 nuevamente: http://www.php.net/manual/es/languag...rorcontrol.php 2. Aplicar "Coding Standard" o formato de código: se trata de escribir el código siguiendo unas normas de formato, indentación, comentarios, etc, para que sea más fácil de leer y entender por todos. No hay un único standard pero se ha hablado largamente sobre el tema. Empieza por adoptar UNO, luego puedes cambiar cuando te dé la gana. Personalmente no tengo preferencias pero recomiendo este:
http://pear.php.net/manual/en/standards.php
Asimismo CUANDO POSTEES EN EL FORO utiliza las etiquetas de formato.
Pregunta: pero si trabajo yo solo en mi proyecto, tengo que adoptar un formato??? Desde el momento que posteas en el foro ya no trabajas solo en tu proyecto... 3. Asignación y comparación: al escribir una instrucción de comparación, escribe primero el valor, luego la variable:
ESTO NO:
ESTO SI:
El motivo es que es muy fácil equivocar la comparación (==) con la asignación (=) y el resultado es incorrecto. De la manera descrita, ante un error por parte del programador, PHP dará un error de sintaxis y el fallo se puede detectar en el momento.
4. Comprobar los recursos externos: recursos externos son todos aquellos que están fuera de PHP mismo, tales como conexiones de bases de datos, archivos, streams, etc. Hay que comprobar siempre la validez de los recursos y aprovechar las funciones de error para obtener valiosa información de debugging:
ESTO NO:
ESTO SI:
De esta manera el error se detecta al instante y además, se puede ver el mensaje concreto. Casi todas los recursos tienen funciones asociadas para ver los errores.
Pregunta: pero si hago esto tengo que agregar un montón de lineas de código, es realmente necesario??? Claro que no, sólo si quieres un software de calidad y evitar 5000 post en forosdelweb... 5. Usar el operador ternario cuando sea posible: es una versión abreviada de if para casos concretos:
ESTO NO:
Código PHP:
Ver original<?php
if($pais == "ARG")
{
$destino = "google.com.ar";
}
else
{
$destino = "google.com";
}
?>
ESTO SI:
Código PHP:
Ver original<?php
$destino = ($pais == 'ARG'?'google.com.ar':'google.com'); //se puede escribir de otras maneras
?>
Se trata unicamente de reducir las lineas de código y por tanto las posibilidades de error.
http://de3.php.net/manual/es/languag...comparison.php 6. Existen desde luego herramientas que ayudan con el debuging pero su uso y configuración quedan fuera del ámbito de este artículo. En cualquier caso siempre son recomendables. Hay que decir que todas implican un cierto proceso de aprendizaje, sobre todo para los que han aprendido a programar con PHP y no conocen otros lenguajes como C o Java. Siempre puedes utilizar la funciones nativas del lenguage que ayudan mucho:
http://de3.php.net/manual/es/functio...-backtrace.php
7. Utiliza funciones como print_r() y var_dump() (mejor aún) para ver qué contienen las variables en la ejecución de un script. Si este es tu script:
Código PHP:
Ver original<?php
if($a)
{
echo 'a es true y estoy aquí';
}
else {
die('A es false, exit()'); }
?>
y siempre obtienes el output 'A es false, exit()' es porque $a es false, no sigas analizando la lógica sin comprobar el valor $a.
Pregunta: por qué $a es siempre false??? ESO ES LO QUE TIENES QUE AVERIGUAR.
8. Aunque PHP es un lenguaje muy permisivo a la hora de manejar variables,
declara siempre las variables antes de utilizarlas. Además de ser más elegante, te ahorra mensajes de Warning y soluciona eventuales problemas de seguridad en versiones antiguas de PHP.
ESTO NO
Código PHP:
Ver original<?php
$array[] = 'Hola';
$array[] = 'Chau';
?>
ESTO SI:
Código PHP:
Ver original<?php
$array[] = 'Hola';
$array[] = 'Chau';
?>
http://de3.php.net/manual/es/ref.var.php
9. Hacer caso los mensajes de error de PHP: no busques más problemas e inicialmente confía en los mensajes del compilador:
significa exactamente eso, no preguntes por qué tienes ese error: lo tienes porque la variables está indefinida.
Pregunta: Por qué la variable está indefinida??? ESO ES LO QUE TIENES QUE AVERIGUAR.
Utiliza Google translator ni no entiendes inglés:
http://translate.google.com/
Error reporting:
http://de3.php.net/manual/es/functio...-reporting.php
10. Siguiendo con el punto 9 y extendiendo las consideraciones iniciales,
busca la información en la fuente y de autoridades. La información proveniente de fuentes no especializadas puede llevarte a nuevos errores y te aleja del problema inicial. La documentación especializada puede ser difícil de digerir al principio pero pronto aprendes y puedes sacarle provecho. Hago notar que no se trata de sobrevalorar o descalificar a nadie, simplemente buscamos una solución a un problema determinado.
FUENTES VALIDAS: php.net, páginas oficiales, pear.com, zend.com
FUENTES SOSPECHOSAS: tu cuñado, la piba que trabaja en la panadería, el profesor de música de la escuela.
Espero que a alguien le sirva, saludos y hasta pronto