“Errores vs.

Buenas prácticas en PHP”

La función header

Este es uno de mis favoritos. Seguro que en más de una ocasión os habréis topado con este
aviso:

Warning: Cannot add header information – headers already sent…

Vale, no es un error, pero es un warning muy molesto que siempre es ocasionado por un
despiste. Esto es provocado porque estamos enviando información duplicada al navegador. Por
un lado, estamos enviando al header que está conformado por datos invisibles al usuario como
las cookies, y por el otro al contenido de la página, conformado por información visibles, para
que me entienda, como la propia página web. Por lo tanto, siempre que tengamos que mostrar
información por pantalla hay que hacerlo ANTES de utilizar la función header. El archivo php.ini
tiene un parámetro con el que podremos deshabilitar ese warning, que se llama
output_buffering. Recomendamos tenerlo habilitado si estamos en un entorno de pruebas
para ser conscientes de que estamos haciendo algo mal.

No formatear las variables de entrada

Aparte de ser un error es un grave problema de seguridad, si no estamos protegidos contra

inyecciones sql. Es común a la hora de recibir las variables de entrada GET o POST no
formatearlas como es debido. Es decir, además de comprobar de si el formato de lo insertado
es correcto, formatearlo con el estilo correcto para ser almacenado en base de datos. Me estoy
refiriendo a buenas prácticas como quitarle los posibles espacios tanto delante como detrás a
una cadena, limpiar el posible html que nos hayan podido colar, formatear bien las comillas
para que se inserte bien en base de datos, codificarlo de manera correcta en el caso que haya
que hacerlo... Este error es un arma de doble filo porque es posible que, cuando te hayas dado
cuenta, tal vez sea demasiado tarde. Ya habrá contenido en base de datos mal formateado
desde hace mucho tiempo.

Error al comparar

Este es el que más rabia me da por lo tonto que es. De manera imprevisible, una variable de tu
código, en un momento determinado, por arte de birlibirloque, cambia de valor haciendo que
crashee el proyecto en general. Este error es un auténtico ninja ya que se esconde muy bien
entre todo el código fuente camuflándose como una sentencia cualquiera. Al final lo
descubres. ¡Estaba ahí desde el principio! ¡¿Cómo no te has podido dar cuenta?! ¡¡Era la
comparación!! Os pongo la imagen del sujeto:
 if ($uno = $dos){

//Aquí lo tenéis

if ($uno == $dos){

//Esto sería lo correcto

?>

En el primer caso no estamos comparando, estamos asignando. De ahí que nuestra variables
cambiase de valor de repente, sin que nos diésemos cuenta.

¿Y el break del switch?

Otro clásico. Implementamos un switch con varias opciones y cuando lo ejecutamos nos damos
cuenta de se están ejecutando todas las opciones, a la vez. Un error que puede provocar un
exceso de carga en el servidor dependiendo de las funciones que tenga cada uno de los case.
Estamos hablando de esto:

$var= 1;

switch($var){

case 1: echo '1';

case 2: echo '2';

case 3: echo '3';

//Di adiós al break y hola a uno de los errores más molestos en PHP

?>

El sistema, al no encontrar el break, entra en la opción correcta y la valida como true. Esto hace
que el resto de las opciones sean ejecutadas también. Un error que, a pesar de ser muy
pesado, es fácil de detectar por lo escandaloso de su comportamiento.
Los caracteres no se muestran bien

Vale, tengo que reconocer que a este le tengo un odio intenso. Aparece poco, pero cuando
aparece es muy difícil de detectar. ¿Os acordáis de la capa de invisibilidad de Harry Potter?
Pues este la usa como el que usa una bufanda, puesto que es un maestro del disfraz.
Ejecutamos la aplicación web y nos damos cuenta de que los acentos no aparecen como
deberían. En su lugar aparecen extraños símbolos como el de las cartas de poker, y letras con
acentos que no habías visto ni en el diccionario de ruso. Amigo, te enfrentas a un error de
codificación. Puede ser debido a múltiples motivos los cuales se pueden entrelazar entre sí.
Puede ser una mala codificación del fichero, puede ser una mala codificación de la base de
datos, puede ser que estemos modificando la codificación en algún momento del código... Lo
ideal es codificar tus proyectos y todo su contenido en UTF-8 para no tener problemas con
acentos y eñes.