Buenas prácticas de programación

[[Delphius]]

Pues si te quieres meter de lleno en lo que es y hace a la calidad y productividad basada en "mediciones" extraídas desde el código fuente entonces se sugiero que le dés más de una leída al libro "Ingeniería de software, un enfoque práctico" de Robert Presman. A lo largo del libro va presentando medidas, métricas e indicadores que pueden ayudarte a sacar algunas conclusiones.

Noto que has puesto demasiado énfasis en lo que es a comentarios. Tanto o más importante que disponer de un buen equilibrio en la cantidad de comentarios y en como uno documenta el código es la legibilidad del código.

Cuando se trabaja en grupo es más que importante tener reglas claras al momento de programar. Si algunos te van a escribir código en español y otros en inglés, o si uno le va a CamelCase y otros a NoMeImporTACAZEH o cosas por el estilo entonces hay un descontrol que ni te cuento.
Mucho mal que pese se debe poner orden en la casa y todos deben respetar un estilo y formato a seguir para que se puedan intercambiar ideas.
Eso de que cada quien tiene su estilo y que el otro se las arregle no va.

Si se define un criterio de nomeclatura, y unas pocas reglas de uso y buenas prácticas todos saldrán ganando y ninguno se sentirá que le cortan su propia manera de programar. Naturalmente, para llegar a esto debe haber una puesta de cada uno del equipo a fin de coordinar entre todos como se han de llevar las cosas.

Si estás interesado, hay herramientas que permiten generar documentación a base de comentarios desde el código, algo parecido a JavaDoc. Una de esas herramientas es DelphiCodeToDoc; hay otros proyectos similares a ese.

Saludos,

[[ElKurgan]]

Yo siempre recomiendo el estupendo manual de estilo de Alexander Hristov... ¡Y además está en perfecto Español!

Saludos

[razonasistemas]

Gracias a todos por contestarme.

Uno de los problemas que tenia era que, al haber subcontratado cosas, especialmente la programación web, pues no tenia acceso al codigo fuente de inmediato, sino una vez entregada y pagada la aplicacion.

Y nos encontrábamos con que el programa subcontratado funcionaba bien, porque cumplía sus funciones, pero luego, cuando había que hacer alguna modificación era una pesadilla :

* Código sin ninguna documentación.
* Algunos programas constaban de un único fichero enorme.
* Funciones larguísimas con el mismo código copiado y pegado.

Y no solo pasaba con lo subcontratado. En algunos desarrollos propios en Delphi o Java también me encontraba con alguna de estas barrabasadas.

Ayer me dedique a leer de cabo a rabo el libro que me recomendó elKurgan, y me he dado cuenta de que lo que yo buscaba es un software llamado analizador estático de código. Me he bajado uno llamado MonitorSource y voy a pelearme con el, a ver si puedo enlazarlo con el svn para poder hacer automáticamente el análisis que necesito.

Saludos

[[AzidRain]]

Un consejo, no subcontrates en esas condiciones pues estás a expensas de lo que el señor que contrates quiera o no hacer, además de que en efecto te entregará código espaguetti en la mayoría de los casos.

Aqui tambien subcontratamos cuando se trata de algún proyecto para el cual no tenemos personal que pueda realizarlo, pero la condición que ponemos siempre es tener acceso al código en todo momento se haya o no pagado (por eso firmamos un contrato) así podemos ir haciendo observaciones y podemos controlar todo el proceso de desarrollo.

En efecto hay gente que no le gusta y quiere entregarte todo hasta el final, pero afortunadamente también hay mucha gente que le da lo mismo mientras el pago sea justo y se cumpla. En algunos casos excepcionales otorgamos un bono adicional por calidad en el desarrollo.