Estaba leyendo estas recomendaciones de Niko para el desarrollo de juegos, y me llamó la atención en particular la última “No vas a tener éxito” porque siempre es bueno que hagamos un reality check sobre lo que hacemos, y también, meditemos sobre por qué las cosas no salen como deberían salir. No me refiero a las cosas fortuitas y fuera de nuestro control, como cambios en Steam que pueden afectar el éxito de nuestro juego, o desinterés del público.

Ciertamente hay que colocar nuestras expectativas en lugar correcto (“No vas a tener éxito” es algo exagerado pero debe estar dentro nuestras 5 primeras estimaciones). Ese sería el punto número uno. El punto número dos sería revisar qué cosas están afectando nuestro éxito, o qué cosas lo pueden afectar. No es fácil hacerse un examen de conciencia y determinar las fallas en nuestro comportamiento, pero si se pueden determinar malos hábitos que son susceptibles de ser corregidos. En mi caso estoy viendo en qué cosas pierdo tiempo al programar, y la lista es grande. Pero resalta algo que puede ser resuelto “fácilmente”, lo he identificado muchas veces y sin embargo sigue ahí, generando problemas y pérdida de tiempo: me refiero a no documentar correctamente y extensivamente el código que escribo.

Es real: yo pierdo minutos u horas trabajando cosas que ya he implementado, o utilizando incorrectamente una función porque la documentación no sirve. Pero el peor caso es la documentación arcana:

[code]
// the regeneration should take care of this
if (!g_planets[pl_idx].ships[i].captured) {
// if it has not been captured, it’s already created –>
// we don’t need to do anything here
continue;
}
[/code]

Cuál es el impacto de este código es algo que no se puede saber leyendo esos dos comentarios. El primero no explica nada: la regeneración se refiere a la regeneración de las naves, pero no dice qué es lo que debe ser atendido, cómo, ni cuando. El segundo es peor, la nave existe, no ha sido capturada, así que no tenemos que hacer nada, se supone que la nave está disponible y visible. Es decir, solamente cuando una nave es capturada debe ser regenerada, o re-inicializada si se quiere. Luego de analizar el código un buen rato podemos deducir lo que hace, o lo que no tiene que hacer. La idea es que los comentarios clarifiquen contexto, el para qué y el por qué ya que el cómo está más o menos visible. En resumen, cuando estoy estoy contra reloj tratando de hacer funcionar un feature, o corregir un bug, lo menos que deseo es encontrarme en mi camino una misteriosa función que se supone que hace algo relacionado con lo que estoy tratando de resolver y solamente tiene un mensaje ufano, risible, inútil: “Esta función hace lo que decidí que hiciera… y lo hace muy bien”. Se cansa uno.