Barrapunto

Aunque el tema se presta a gracietas varias yo voy a ser un poco soso. Mi costumbre es:

1. escribir primero los comentarios, procurando que no pasen de una línea. La estructura del programa debe quedar reflejada en este paso.

2. Usar siempre nombres de funciones y de variables largos y expresivos (que casi formen frases en lenguaje natural). Aborrezco los i, j en los bucles: mejor iCol, iFila, iNum, etc.

3. Borrar los comentarios que queden superfluos después de haber intentado que el código sea autoexplicativo.

4. Añadir comentarios allí donde, al día siguiente, la cosa no sea completamente obvia para mí.

5. Aunque me suponga alguna línea extra, usar variables cuando hay que cargar un valor de, por ejemplo, una BD o una fuente externa, en lugar de incrustar la expresión-fuente como parte de la expresión-destino.

6. Usar comentarios con cierta dosis de metáfora o de humor, si eso ayuda a reducir una explicación pedante.

7. En el raro caso de que quiera que alguien no lo entienda, lo ofusco o lo bestia. Aunque en realidad, a pesar de todos los esfuerzos por programar con claridad, en cuanto el programa es complejo a las dos semanas no lo entiende ni su padre/madre.

8. Lo de Refactorizar lo hago desde pequeñito, antes de que le pusieran nombre. Le llamábamos "sobetear". Y también lo de programar en pareja. Tuve la suerte de congeniar con mi compañero y podíamos cambiar continuamente de papeles (analizarprogramar). Salvo que sea un programa trivial, no es posible prediseñarlo completamente; y el que al menos dos lo entiendan, te salva bastante del solipsismo.

Aborrezco los i, j en los bucles: mejor iCol, iFila, iNum, etc.

Cuando se usa i, j (o si quieres f, c) el código queda mucho más compacto y fácil de verificar de un vistazo. Si no vas a hacer un uso extraño de i y j (por ejemplo array[i*j-4][j+2], entonces un array[i][j] es mucho más cómodo y fácil de leer que un arrayDoble[iFila][iCol]). Y nada dice que tengas siempre que seguir el mismo criterio para nombrar variables en todos los casos: No hay técnicas mejores para todo, hay técnicas mejores para "esto" y peores para lo "otro".

3. Borrar los comentarios que queden superfluos después de haber intentado que el código sea autoexplicativo.
4. Añadir comentarios allí donde, al día siguiente, la cosa no sea completamente obvia para mí.

Me gusta eso. Yo lo llamaría, saber aprovechar los errores para mejorar o aprendizaje continuo.

7. En el raro caso de que quiera que alguien no lo entienda, lo ofusco o lo bestia.

Yo para eso uso programas que ofusquen el código, incluso alguno hecho por mí. así puedes modificar el original y volver a ofuscar siempre que quieras.

Aunque en realidad, a pesar de todos los esfuerzos por programar con claridad, en cuanto el programa es complejo a las dos semanas no lo entiende ni su padre/madre.

Esto es que aún no programas todo lo bien que debieras. Si tuvieras que hacer modificaciones al programa MUY a menudo, y tuvieras MUCHOS programas hechos por ti que mantener, al final terminarías por elegir un método sostenible o perecer.

Normalmente esto sucede por no partir el código en cachitos lo suficientemente pequeños como para ser comprensibles de un vistazo. A menudo se tiende a mezclar la máxima funcionalidad en un sólo bloque código, lo que rompe la reutilización y hace que mantenerlo sea infernal. Si cada porción de código hace una cosa y sólo una, puede probarse por separado, reutilizarse o derivarse fácilmente.

¿Por qué todos son "pobrecito hablador"? Es como si hablase con un muerto