Blogia
softinspain

Código "bonito"

A mi personalmente me gusta que el código que escribo tenga una buena "apariencia" y lo digo en el más puro sentido estetico. Primero el código debe funcionar correctamente, eso no hay duda, pero además me gusta que esté bien estructurado, bien indentado, con nombres de variables que tengan sentido.

Esto lo vengo haciendo desde que escribía programas en Clipper, en la empresa que trabajaba, "heredé" un código de una aplicación de gestión, que si bien funcionaba, era casi imposible de "leer" el código, así que lo primero que hacía cuando abría un nuevo módulo era "reorganizar" el código de forma que me fuera más sencillo entenderlo y así poder modificarlo. De ahí me quedó ciertas "manías":

-Las indentaciones las hago a 3 espacios (aunque ahora en la empresa acabamos de estandarizarlo a 2)
-Todas las variables tienen una "notación hungara" que indican que tipo de datos contienen. En Clipper TODAS las variables eran de cualquier tipo, es decir, no estaban tipificadas, el mismo identificador servía para un entero, para una cadena o un array, pero yo insistía en que debíamos ser estrictos en esto.
-Cuando tengo una secuencia de instrucciones iguales, por ejemplo asignación de campos, alineo los paréntesis, los iguales, todo para que sea más sencillo el leer el código. Ejemplo (en pseudolenguaje):

ALBARAN.CLIENTE := CLIENTE.CODIGO;
ALBARAN.FECHA := HOY();
ALBARAN.NUMERO := CONTADORES.NUEVO('ALBARANES');
ALBARAN.FPAG := 0;

Pienso que es una ayuda más para facilitar la lectura de código, por ese motivo siempre he preferido lenguajes con una sintáxis más literal (Pascal, Python) frente a otros mas "simbolicos" (C, Java, Php, Perl)

Y tú.... ¿Como escribes el código? ¿Lo dejas "bonito"? ¿O mientras funcione es válido?

5 comentarios

Albin -

Yo intento que variables relacionadas tengan la misma longitud, que los iguales en las asignaciones esten alineados, e incluso en llamadas sucesivas a la misma función, que las comas de los parámetros estén alinadas.

Algo que me molesta pero resulta inevitable es que if e elseif nunca pueden medir lo mismo, y los parentesis quedan raros.

Tambien procuro no utilizar líneas para "poca cosa" salvo con los }

Tantas manías que a veces cuesta pensar en el verdadero problema.

Jose Alberto -

Yo siempre he pensado que el código debe ser entendible para los humanos, que el ordenador, mientras sintácticamente sea válido le da igual, como si queremos llamar a las variables "ajskljas" "qwuqwu8282"

Lo importante es que otros programadores sean capaces de entender el código que está escrito.

Jaime Irurzun -

Yo sí que intento también que quede limpio, en su día me lo propuse: http://www.codigoescrito.com/archivos/000007.html

Lo de nombrar variables y métodos en spanglish es lo mejor, jejeje, yo también lo hago ;)

Jose Alberto -

Actualmente trabajo con Delphi y no le veo tanta utilidad a la notación hungara, porque el propio compilador me impide hacer asignaciones erróneas, pero con Clipper ésto no pasaba y "necesitaba" de alguna forma controlarlo.

En las propiedades de los objetos suelo utilizar castellano, pero los metodos los suelo nombrar en ingles o spanglish...

GetDtoProntoPago :)
MakeFactura :)

Un saludo.

Juanjo Navarro -

Por supuesto intento que quede legible el código, sino luego no hay quien lo mantenga.

Aparte de ese tipo de "ajustes" (alinear elementos comunes, las asignaciones), respetar indentaciones, etc, lo que yo encuentro básico para hacer el código legible es elegir bien los nombres de los atributos (variables) y métodos. De este modo el código se puede "leer" en castellano, con métodos que son verbos, etc

Por eso mismo yo "odio" la notación hungara. Me resulta dificil leer código con ella, con todos esos prefijos molestando la lectura. Aparte de los problemas que trae cuando cambias el tipo de la variable a mitad de proyecto y tienes todas las referencias apuntando al antiguo nombre, uff... En fin, a mi no me añade legibilidad esa notación.