Errores de programación II

Segunda entrega de los errores de programación que nos hemos ido encontrando en GotSpots.

Si no lo has hecho aún, puedes leer aquí la primera entrega.

3. Mostrar mensajes de error no tratados

Si se produce alguna excepción, el software desarrollado nunca debe mostrar a los usuarios los mensajes de error por defecto de los lenguajes utilizados.

Si hay que mostrar algún mensaje debe ser útil para el usuario, no algo que le confundirá más aún. Además, los mensajes por defecto son una fuente estupenda de información para aquellos que intenten saltarse la seguridad del servidor.

Sin entrar en materia de seguridad, un ejemplo de error al poner algún dato no permitido en un formulario.

Error en la consulta limitada: SELECT * FROM usuarios WHERE nombre=’$nombre’  ORDER BY apellidos DESC LIMIT -15,15. Mysql dijo: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘-15,15’ at line 1

Esto no da ningún tipo de información al usuario, más bien le desorienta, mientras que para alguien malintencionado le está mostrando la consulta que se ejecuta en la base de datos e indicándole la posibilidad de realizar un ataque mediante inyección de SQL.

Lo que hay que hacer es que se muestren siempre errores tratados, en este caso podría ser.

Se ha producido un error. Inténtelo más tarde.

 

4. No usar nombres con sentido y/o inconsistentes entre llamadas

A lo largo del desarrollo de un proyecto y para futuras revisiones, que los nombres tengan sentido y sean descriptivos es fundamental en todo lo que se utilice: directorios, archivos, funciones, variables, etc.

No es lo mismo una variable que sea “nua=5 que “numArticulos=5“, o el de una función “fun5” que “generarImagen“.

Aunque en el momento que se desarrolla se tenga muy claro la función de cada elemento y su interacción entre ellos, hay que tener siempre presente el mañana.

Lo que hoy está claro y es sencillo, mañana puede suponer varias horas de leer y releer líneas de código. Y por supuesto está el asunto de que algún compañero tenga que trabajar con tu código, si no lo entiende quien lo ha escrito imagínate alguien que es la primera vez que lo ve.

Otro fallo muy común y que dificulta la lectura del código, es llamar de manera diferente a variables que se mandan de un lado a otro, aunque sean descriptivas.

¿Qué es mas claro? 

Este primer ejemplo

var existencias = 5;

var procedenciaArt = "Castellon";


( aquí va el código que envía las variables de JavaScript a un servicio web Php)


$cantidad = $_POST['existencias'];

$lugar = $_POST['procedenciaArt'];

$query = " SELECT * FROM articulos WHERE numArticulos = '$cantidad' AND origen='$lugar' ";

o el segundo

var numArticulos = 5;

var origen = "Castellon";

  ( aquí va el código que envía las variables de JavaScript a un servicio web Php)

$numArticulos = $_POST[' numArticulos'];

$origen = $_POST['origen'];

$query = " SELECT * FROM articulos WHERE numArticulos= '$numArticulos' AND origen ='$origen' ";

Y eso que esto es un ejemplo muy sencillo.

 

Por hoy nada más, os esperamos en la próxima entrega.

Un comentario

  1. Pingback: Errores de Programación I - GotBlog

Deja un comentario