Barrapunto

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