Llevo ya un tiempo como desarrollador y me he topado muchas veces con proyectos donde el código es ilegible e incompresible, y veo con suma preocupación que muchos desarrolladores no le prestan la debida atención a este tema, ¿será por la falta de conocimiento, por la pereza de darnos un trabajo extra o por creer que es una práctica pasada de moda?.
«En el apuro por cumplir un plazo de desarrollo de aplicaciones, es fácil descuidar el estilo y la legibilidad.» Nigel Cheshire
¿Por que deberíamos de apegarnos a estas reglas? Por lo siguientes motivos:
- Hacer mas legible el código
- El 80% del coste de la vida útil de una pieza de software se destina al mantenimiento
- Casi ningún software se mantendrá durante toda su vida, por el autor original
- Dentro de un equipo de programadores es mas fácil entender el código y a la vez mas fácil depurarlo
- Hacer que el código sea mas fácil de reutilizarlo
- Reducir los números de errores lógicos en el código y el tiempo en su depuración.
«Cuando usted se siente obligado a añadir un comentario, considere la posibilidad de volver a escribir el código para hacerlo más claro.» SUN Microsystems
Muchas veces no reparamos en las consecuencias que pueda tener a largo plazo, el no seguir estas normas, pasándolas por alto o dejándolos para otro momento. Veamos el siguiente cuadro
Como vemos las consecuencias pueden ser desagradables, ya que incrementarán el tiempo y el costo de mantenimiento, hasta llegar al punto que va ser mucho más sencillo volverlo a desarrollar todo desde cero. Empecemos!
Estilo de programación
Hace referencia a como formateamos el código que estamos desarrollando, tales como llaves, indentación, paréntesis, el espaciado, etc. Esto puede diferir entre lenguajes de programación. A continuación les dejo una pequeña guía personal basándome en los estilos de Java, C# y PHP 1. Indentación Sobre como indentar hay varios estilos tales como: Allman, K&R, BSD KN, Whitesmiths, etc. Considero que el estilo Allman es el mejor, el cual dice que debemos usar los sangrados para indentar el código, nunca espacios. Poner las llaves de control en la línea subsiguiente.
2. Saltos de Línea
- Añadir un salto de línea después del cierres de los paréntesis de los parámetros.
- Añadir un salto de línea después un punto y coma, cuando termina la sentencia.
3. Espacios y líneas en blanco
- Usar espacios en blanco para mejorar la legibilidad del código.
- Usar espacios en blanco e ambos lados del operador de símbolos, después de comas y después de las declaraciones.
- Usar líneas en blanco para separar trozos de código.
- Usar líneas en blanco antes de cada método dentro de la clase.
4. Longitud de la línea Evite las líneas de mas de 80 caracteres cuando supera se debe córtalo bajo los siguiente principios
- Salto de línea después de la coma.
- Salto de línea después de un operador.
- Alinear la nueva línea con el principio de la expresión en el mismo nivel en la línea anterior.
Hasta aquí llegamos hoy, en la próxima veremos sobre la convención de nombres
Hola Pablo, cada lenguaje tiene un standar en particular de las cuales difieren unas con otras, la idea es que un desarrollador tenga un estilo y lo pueda aplicar en el lenguaje de turno, ya sea php, C#, java, etc, y no preocuparse por las reglas de cada uno.
Te invito a que leas la e part II , y verás en las referencias que también me base en el estilo de Zend Framewok
Saludos!
Esta bueno que en general se adopten standar pero no cualquiera. Seria mejor que todos siguieramos uno para conseguir un entendimiento general. La gente de Zend armo una documentacion para este standar
http://framework.zend.com/manual/en/coding-standard.html
En mi blog arme un resumen de esa documentación, y hay algunas diferencias con lo que mencionas
http://zendhispano.blogspot.com/2008/03/mejores-practias-zend.html
Buen día.
Están caídos los links.