Buenas prácticas de programación

[Ñuño Martínez]

Voy a comentarte algunas cosillas:

Empezado por razonasistemas

* Tamaño del fichero. Si se meten miles de lineas en un solo fichero, éste se convierte en ilegible.

* Tamaño de las funciones. Cuando estudiaba se decía que una función no debería ser mayor que el tamaño de la pantalla. Así que una función con mas de x lineas seria un criterio.

* Ratio mínimo de comentarios. Debería haber un ratio lineas_de_comentario / lineas_totales mínimo. Estos comentarios deberían de ser útiles, ya que hace años traté de instaurar un estilo de comentarios parecido al javadoc y me encontré con que la gente ponía como comentarios en un button.click, por ejemplo "@param sender componente que activa el evento" o "@return no se devuelven resultados" o sea, comentarios sin ningún valor.

* Comentarios en funciones. Si una función tiene mas de x lineas entonces es compleja y debería de tener en su cabecera un comentario explicando el funcionamiento.

Lo que hace ilegible el código no es el tamaño, sino la documentación y el estilo. Si usas nombre con significados reales, bien formateado (por ejemplo, con CamelCase o usando_caracter_subrayado), bien indexado y con comentarios bien redactados, da igual cuán largo sea.

He visto funciones de pocas líneas en las que es imposible saber qué hacen y menos aún cómo lo hacen, sin embargo he visto funciones de varias páginas en las que el algoritmo está claro y diáfano.

Personalmente creo que limitar el tamaño "porque sí" es una tontería, aparte de que puede afectar al rendimiento al multiplicar las llamadas. Recuerda que cada llamada a método o función es tiempo extra, mayor cuantos más parámetros tengan.

[Delfino]

A partir de Delphi 2007 existe la posibilidad de definir Metrics y Audits según el gusto de cada uno, basta con habilitar el project para UML en Model View y pinchar con el botón derecho sobre los diagramas generados ..

[[AzidRain]]

Me acordé cuando leí el comentario de Delphius de cuando en la universidad presenté un proyecto en un concurso (el cual por fortuna gané) y utilcé el modelo COCOMO para estimar los costos del mismo en caso de comercializarlo. Eran por ahí del '94 cuando lo hice y ni siquiera era Delphi. Ahora ya está en desuso ese modelo, con el advenimiento de la OOP y las enseñanzas de Don Grady Booch.

Delphi-To-Doc es bueno pero a mi juicio no iguala la calidad y facilidad de JavaDoc donde el propio IDE que utilices (Eclipse o Netbeans) reconoce los comentarios y te proporciona recordatorios de parámetros y demás cosas, simplemente no he encontrado algo parecido.

Al final, la documentación tiene como función principal explicar lo que el código hace, como lo hace y por qué lo hace así.

Lo que si es muy importante es estandarizar detalles en el estilo: Usar o no CamelCase, o subrayados, definir índices de ciclos a partir de "i,j,k..etc.", no utilizar variables de una sola letra, utilizar constantes siempre que un valor se repita más de una vez y colocarlas en una sola unidad para poder tenerlas a la mano en cualquier momento, etc.