12 señales de que eres un mal programador

Leyendo mundogeek me encuentro con la traducción al español de un articulo de Damien Katz (http://damienkatz.net) en la que expone 12 interesantes señales que te indican que eres un mal programador xD

Comparto unas cuantas por acá:

1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)

2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.

4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.

6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.

Para ver las demás puedes visitar mundogeek.net para la versión en español o acá para la versión en ingles

Saludos

El gordo