Guía para el buen programador en un mal día.

Es bastante común encontrar colecciones de pequeños consejos de estilo de codificación, “tips” del tipo:

• Comenta el por qué y no el cómo.
• No copies y pegues sin entender qué es lo que estás copiando y pegando.
• Los nombres de las variables deben indicar qué dato contienen (totalVentas) y no su tipo o uso dentro del código (auxDecimal).
• No incluyas el nombre de la clase en el nombre de un método(Cliente.Actualizar en vez de Cliente.ActualizarCliente).
• Resuelve el problema antes de comenzar a codificar.

… y un largo etcétera que pueden buscar por ahí. Es bueno conocerlos, releerlos de vez en cuando, tenerlos en la cabeza.

Así, como estamos motivados para codificar cada vez mejor, en forma más legible, elegante, eficiente y fácil de mantener, son de gran ayuda.

Pero hay veces que uno tiene un día de m***. Enojado con la tarea, el trabajo, el mundo o la vida en general. O sin ganas de trabajar. O tal vez medio dormido después de una noche de juerga.

Hay veces que uno no tiene ganas de hacer las cosas bien. El que diga que no le pasó nunca, miente.

Yo aconsejaría no codificar en ese estado “de desgracia”, pero hay veces que la tarea es ineludible o que la tarea misma es la que nos pone de mal humor.

Así que empecé a pensar en tips para programar “en esos días de angustia y dolor”. Se me hace bastante más difícil, sólo logré esbozar algunas propuestas:

• ¿Seguro que no puede resolverse sin codificar?
• ¿O mejor dejarlo para otro día?
• En fin… Si estamos modificando algo, considerar borrarlo e implementarlo de vuelta. Lo que hagamos en este estado tampoco será de gran calidad, de todas maneras.
• Es preferible no comentar el código a comentar cualquier cosa.
• Al copiar y pegar código sin mirar borrar los comentarios copiados.
• Para días no tan malos, seguir las dos indicaciones anteriores y poner un comentario al principio (también al final, ¿será mucho pedir?) de lo copiado, indicando qué pretendemos que haga (y una plegaria pidiendo que por favor lo haga).
• Asegurarse de que el muerto quede encerrado en un sólo procedimiento o clase.
• Prestar atención aunque sea a los nombres y parámetros de los elementos públicos, no hay por qué molestar a los demás con nuestra desgracia… ok, los nombres de los privados pueden quedar para otro día.
• Lanzar una excepción del tipo NotImplementedException o similar para casos del tipo “nah, eso no se va a dar nunca”. Es mejor que algún caso raro falte y se note a que el sistema “siga de largo” haciendo cualquier cosa.
• ¿Todo en un sólo procedimiento de 500 líneas o más? Bueno, por lo menos dejar un par de renglones entre las diferentes partes. O si el día no es tan malo ponerle una línea de guiones de separación.
• Es mejor poner el código de un recurso inexistente que hardcodear una cadena en la interfaz con el usuario (odio cuando los sistemas quedan traducidos a medias).
• La performance puede quedar para el final… o mejor para mañana. Funciona, ¿no?

La consigna es “algo es algo”. ¿Ideas?