Convenio de codificación general

Los métodos, funciones y procedimientos se nombrarán describiendo la acción que realizan mediante el uso de verbos. La primera letra del nombre deberá estar en minúsculas. Si el nombre está formado por más de una palabra, a partir de la segunda palabra la primera letra deberá estar en mayúsculas.

Es necesario nombrar las variables de manera que facilite la comprensión del código fuente, manteniendo una cierta lógica dentro del modelo de negocio que representan. Se utilizarán sustantivos escritos en minúsculas. Si el nombre de la variable está formado por más de una palabra, a partir de la segunda palabra, la primera letra de cada palabra deberá estar en mayúsculas. De esta manera, el desarrollador obtendrá un código más intuitivo y sencillo de mantener.

Las constantes deben nombrarse todas en mayúsculas, separando las palabras que formen parte del nombre con el carácter de subrayado (_).

Se debe controlar el tamaño del código fuente estructurado. Éste no debe sobrepasar las 2000 líneas de código ya que el superar esta extensión indicará que, probablemente, se está empleando un mal diseño.

La longitud de un método no debe exceder de cien líneas de código sin una causa justificada, intentando no agrupar excesiva funcionalidad dentro del mismo. El superar esta longitud provoca que la detección de un error sea compleja, dificultando la legibilidad y el mantenimiento del código.

Se deben programar líneas que, como máximo, tengan una longitud de 100 caracteres, lo que hace que el código sea más práctico y eficiente. En cada línea sólo irá una instrucción, para evitar que la comprensión del código sea dificultosa.

El corte en las expresiones muy largas se realizará de tal forma que no se pierda la legibilidad, dividiendo la línea tras una coma o antes de un operador.

Se debe usar un estilo de sangría en lenguajes de programación para tabular o delimitar bloques lógicos de código. Usando un estilo lógico y consistente se consigue que el código realizado sea más legible. El estilo de sangría se propone en los convenios específicos de cada lenguaje en particular.

Se deben emplear líneas en blanco para separar distintos bloques de código, de manera que se agrupen líneas de código que estén relacionadas. Por ejemplo, deben emplearse parar separar distintas declaraciones de clases o métodos entre ellas o, dentro de una clase, para separar la declaración de la última variable de la del primer método. Además, se deberán utilizar líneas para separar los comentarios de cabecera del fichero del resto del contenido del fichero.

Se utilizarán espacios en blanco tras una palabra reservada y su paréntesis asociado. También entre una palabra reservada, o un paréntesis de cierre, y una apertura de llaves. Otros casos en los que se utilizarán un espacio en blanco son tras una coma en una lista o tras un punto y coma en una sentencia for. No se utilizará un espacio en blanco entre el nombre de un método y la apertura de su paréntesis o tras la apertura o cierre de paréntesis o corchetes.

En estructuras de decisión es necesario el uso de variables booleanas, ya que la no utilización de estas variables provoca que el código sea más complejo y difícil de entender, provocando incluso algunos errores en su concepción.

El uso de estructuras de control lógicas para bucles también es parte de un buen estilo de programación. Ayuda a quien esté leyendo el código a entender la secuencia de ejecución (en programación imperativa).

Es obligatorio que, cada vez que se necesite hacer uso de un valor numérico concreto en el código, este valor se almacene en una constante. Esto indica el origen del valor numérico y reduce el coste de mantenimiento ante cualquier modificación que afecte a la estructura. 

Las llamadas a los métodos no deben contener más de 10 parámetros si no existe una causa justificada para ello. De esta manera, se asegura que los métodos no se encuentran sobrecargados de funcionalidad, favoreciendo el mantenimiento eficiente del código.

Cuando se elaboren búsqueda por cadenas de texto no se debe hacer discriminación por mayúsculas, minúsculas o acentuación a la hora de obtener los registros asociados a la búsqueda.

Es obligatorio emplear la codificación de caractéres UTF-8 siempre que el fichero lo permita. El empleo de esta codificación facilita la portabilidad y evitará futuros problemas en la generación de código fuente documentado.

Hay que usar nombres sencillos y descriptivos a la hora de desarrollar el código para hacer la lectura mucho más fácil. Los comentarios deben ser sólo una herramienta para decir lo que no se puede decir en el código, de modo que se pueda entender lo que dice sin necesidad de indicarlo en otro lenguaje.

Los comentarios deben favorecer la riqueza de la comprensión y no introducir una mayor complejidad en la comprensión del código.

Los comentarios se realizarán por bloques, minimizando los comentarios por líneas, salvo aclaraciones en un código complejo o para reflejar la importancia de una línea dentro de la ejecución del código. Estós comentarios se harán al final de la línea.

Se comentarán las interfaces, las clases y los métodos para que el código quede documentado de forma clara y concisa, facilitando así la legibilidad y el mantenimiento del código.

En cada línea sólo irá una instrucción, para evitar que la comprensión del código sea dificultosa.