12 señales de que eres un mal programador

Visto en Digg. Puede que no esté de acuerdo con todas, pero es una lectura interesante.

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.

7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.

8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan «Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo.» En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama «racionalizar tus acciones».

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al «on error next» de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.

129 comentarios en «12 señales de que eres un mal programador»

  1. Bueno yo sólo programo por hobby y no me gusta Java.
    Añadiría una 13 que es la de no utilizaré los punteros ni aunque me maten. Es que los odiooo!!
    Vete a saber cuáles serían las 12 para saber si eres un mal matemático 😉

    Saludos

    1. ¿Punteros? a mi me encantan, los he usado siempre que he podido porque son muy potentes, o acaso no conduces un ferrari por ser muy potente? te puede dar miedo pero siempre puedes conducir mas despacio y seguir las normas de circulacion jajaja, bueno lo dicho a mi los punteros me encanta y en c, c++ es primordial saber manejarlos de forma correcta yo lo que odio mas bien es como funcionan otros lenguajes que lo toman todo por referencia cuando quieres pasar un valor, no recuerdo caules hacian eso y te liaban sobre todo cuando manejas unos cuantos lenguajes y tienes que estar incluso en el mismo dia cambiando entre 3 o 4 lenguajes distintos de programacion.

  2. Jajaja genial. Gracias xD
    Lo que más me gusta de este texto es que llama malos programadores a todos mis primeros profesores xD

    Perdón si peco de pedante, pero tengo que decir que me chirría muchíiiisimo cada vez que leo un «eventualmente», porque es una palabra que las raras veces que alguien la usa en español es para traducir erroneamente «eventually» del inglés. Aunque no puedo mirar la fuente original (Digg effect) y a lo mejor sí que está bien.

  3. Algunas cosas son ciertas, otras graciosas, y otras no estoy de acuerdo en absoluto.

    Modelar en UML (o en lo que quieras!) es muy bueno. Si puedes llegar a una abstraccion que no sea necesariamente codigo, puedes implementarlo en el lenguaje que desees.
    Hacer un diseño de alto nivel es bueno, tener un diseño de tu modelo de datos, y como se comportara, basicamente, ante lo que quieras que haga el software, es bueno.
    Considero pesima idea, cuando uno se pone a desarrollar, sentarse a tirar lineas de codigo sin pensar lo que uno va a hacer. (UML o lo que sea, las modas no me importan, aunque es bueno usar una convencion que todos entiendan por igual).

    Que los patrones hacen las cosas mas complicadas, es una mentira… Los patrones mal utilizados hacen las cosas mas complicadas (que pasa en muchos casos, pero ese es oooootro tema).
    Los patrones son una simple convencion, para poder transmitir ideas de una manera sencilla… explicar un proxy, o un decorator, seria complicado si no existiera «el patron» que dice que un «proxy» es tal o cual cosa… (Aunque si opino que mucha gente abusa de los patrones, porque son «cool»).
    De todas formas, el libro de «design patterns», en smalltalk, sirve mucho para abrir la cabeza respecto a muchos temas…

    Yo creo que uno de los peores errores de un programador, es pensar que tiene la verdad absoluta sobre un tema, y se aplica a casi todo (y con eso podemos resumir muchos de los puntos que estan ahi listados).

    De todas formas, muy buen post, fue entretenido. 🙂

  4. Buf, a mí me han cateado prácticas por eso de poner varios returns… xDDD Por suerte creo que no puedo darme por aludido por ninguna de ellas (aunque Java es lo que más uso, pero por imposición :P), pero es curioso como al menos 6 de estos puntos son exactamente lo que se enseña en la carrera de informática… (vamos, yo tengo una asignatura que consiste en hacer una práctica sin patrones, y después destrozarla utilizando varios de ellos 😛 )

  5. Yo discrepo en bastantes puntos, quizá sea un pésimo programador, pero no me hará cambiar de opinión.

    4. «¡OH DIOS MÍO! ¡PATRONES!»

    Si aplicas mal un patrón, obviamente estará mal y estarás añadiendo una complejidad enorme, pero decir que por usar un patrón tu código es malo, manda cojones. Esto me da que pensar que el autor no conoce los patrones e intenta autojustificarse a si mismo. Los patrones son geniales, son un medio de comunicación en los diseños, no un fin en la programación.

    5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.

    Pues hombre si programas en Java, te la tocan pequeñas optimizaciones que puedas hacer, pero si programas en C para dispositivos embebidos o similares, las optimizaciones cuentan y mucho. Hacer una comparación en C con operaciones binarias en vez de comparadores decimales te ahorra ciclos, y cuando tenga que programar en ese entorno aplicaré cada uno de los posibles trucos/tips/hacks que conozco y pueda llegar a conocer.

    6. Piensas que ninguna función/método debería tener más de un return.

    Esta es la que más me duele. Ninguna función debería tener más de un return, salvo quizá return debido a excepciones o fallos. Y esto no lo digo yo, lo dice la coherencia, el sentido común, todos los coding standards que mencionan el tema y cualquier libro de prácticas de programación.

    11. Modelas todo tu código en UML antes de escribirlo.

    En esta, el autor (en los comentarios de la página) ha matizado que hay que resaltar el todo. Obviamente usar UML literalmente (con todos tus diagramas, todos completos y tal) es una perdida de tiempo. Pero cualquier programador que sea mínimamente decente conocerá y usará UML antes de escribir una puta linea de código. Papel y boli son las mejores herramientas que existen para la programación.

    @Cristobal, los punteros son operandos de programación normales y necesarios, supongo que si dices que no conoces Java y que no usas punteros, serás programador aficionado en php o similar. Los punteros son necesarios, muy comunes y usuales, aunque en pocas generaciones la gente ya ni sabrá qué son… asusta.

    1. Totalmente de acuerdo con tu respuesta, hay cosas que si tendrán razón, pero otras,…
      Personalmente la que mas me han dolido son:
      6. Piensas que ninguna función/método debería tener más de un return.
      11. Modelas todo tu código en UML antes de escribirlo.

      Pero para gustos colores, cada uno tiene su forma de hacerlo.

    2. De acuerdo en todo menos en los returns. En algunos casos intentar poner solo un return en un método lo hace mucho mas complicado de leer. No creo que valga como practica habitual pero la opción esta ahí y no debería descartarse.

  6. Se dicen varos returns cuando haces por ejemplo:

    public int valorAbsoluto(int x) {
    if(x>0)
    return x;
    else
    return -x;
    }

    obviamente la funcion retornará siempre un único valor.

  7. Bueno es que no soy programador, soy matemático, pero me gusta programar; sobre todo en C++.
    Por eso, como soy aficionadillo me cuesta usar los punteros, máxime cuando no los entendí en visual c++

    Saludos 🙂

  8. A ver. Cuando se mete con los patrones lo hace con esa manía que tienen algunos de tener el libro del Gang of Four al lado y pasarse las horas muertas buscando qué patrón podría casar remotamente con su problema para meterlo con calzador.

    No creo que usar patrones sea malo. Es malo usar patrones porque si, porque queda guay.

    Y como dice Blaxter sobre el 11, no quiere decir que usar UML sea malo. Evidentemente sería una absurdez. Es malo hacer 20 diagramas para cualquier tontería aunque sea un hola mundo. Para cada cosa su justa medida.

    Y sobre los múltiples returns. En general son una mala práctica, pero no existe una regla de oro que diga que siempre lo son. En algunos casos es justo lo que necesitas. Espero que a Emper no se lo hayan enseñado como una regla escrita en piedra, porque sus profesores serían unos cretinos, francamente.

    Relacionado, una discusión sobre los multiples returns en el wiki de ContentCreation: Single Function Exit Point

  9. Yo discrepo en algún punto.

    3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.

    Por regla general escribir una función muy larga, no suele ser una buena señal, probablemente haya alguna otra forma más sencillo de hacer las cosas. Algunas veces no hay más remedio y la función es muy larga, pero no creo que sea lo normal.

    4. «¡OH DIOS MÍO! ¡PATRONES!»

    Opino lo mismo que Blaxter. Aunque no creo que haya que ver patrones por todos lados. Creo que es necesario tener una buena biblioteca/web de referencia y ante problemas complejos o habituales no reinventar la rueda.

    5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.

    Yo diría que esta es muy, muy subjetiva. En general no creo que haya que revisar los ciclos de CPU de las aplicaciones, aunque hay funciones en las que se debería poner un poco de cuidado en este punto. Por ejemplo cuando se trata de funciones que se repiten mucho o cuyo orden es grande, merece la pena dedicar un poco de tiempo a la función e intentar ahorrar tiempo. Esto hablando de programas de alto nivel. No entro en situaciones de dispositivos integrados o núcleos de sistema.

    Por lo demás hay dos puntos que son controvertidos y que creo que tienen más de sentido común que de regla escrita. Así el tema del UML y los returns.

    Sobre el UML, si algo he aprendido trabajando es que no merece la pena hacer un diagrama UML exhaustivo. Es suficiente con explicar los detalles importantes y las relaciones, que es lo que cuesta ver en el código.

    En cuanto a los returns, intento no escribir más de uno por función, pero hay casos en los que queda mucho más claro tener algún return más.

  10. Estoy bastante de acuerdo con Lezer.
    Zoo, ya sabes que alguno de los profesores que pululan por la uni sí que son muy cretinos, no te cuento nada nuevo. Sobre los returns lo que no tiene sentido es que te obliguen a escribir sólo uno, cuando hay ocasiones en las que queda más claro utilizar una condicional y dos returns, sólo por ponernos puritanos. A cada ocasión lo que se merece.

  11. Pues yo estoy de acuerdo en todos los puntos…y creo que no me encaja ninguno. No tengo prejuicios contra como programe cada uno, pero…añadiria un 13: Siempre hay uno que tiene que revisar tu código, lo cual te convierte en un completo incompetente

  12. En mi opinión, estos puntos de vista parecen diseñados por alguien que tiene la grandísima suerte de programar sólo por hobby, porque si no hay algunos puntos que no entiendo.

    El primero es el de Java. Se perfectamente que en python te puedes hacer pequeños scripts con poco código que te resuelven grandes problemas, pero a un cliente no puedes instalarle python para que haga una pequeña tarea, y menos aún si tu empresa no da soporte «oficial» para ese lenguaje.

    Lo de los return también es un tanto absurdo. Si tienes un par de if anidados y en el más interior se obtiene la respuesta, pero en el más exterior se puede comprobar que no hay respuesta, ¿por qué no poner 2?

    Sobre los patrones estoy de acuerdo, es absurdo usarlos al tuntun, pero para hacer un diseño reutilizable a veces hay que usarlos. Si no, hacer un componente puede ser un infierno. Ni tanto ni tan calvo.

    Por último, hacer un diagrama UML es vital para documentar un proyecto y, sobre todo, para que cuando dentro de 8 meses (por decir algo) vuelvas a tener que tocar alguna línea, o más aún si es alguien que tiene que tocar el proyecto por primera vez, tenga un pequeño mapa con el que orientarse.

    En resumen, que me parece más bien unas manías que tiene el que escribió estos «12 mandamientos» que realmente unas buenas pautas. Quizás para programarte tus programillas estén bien (y en mi casa más o menos lo cumplo), pero para el trabajo no los veo muy adecuados.

  13. Pingback: 12 señales de que eres un mal programador // menéame

  14. El problema no es que sean todos los usuarios tontos, si no que un usuario tonto te puede mandar todo al traste. La programación sería más sencilla si no hubiera usuarios, jeje

  15. El problema no es que sean todos los usuarios tontos, si no que un usuario tonto te puede mandar todo al traste. La programación sería más sencilla si no hubiera usuarios, jeje

    Eso me recuerda a una cita, que ahora mismo no se de quién es y que decía algo así como:

    La programación es una carrera entre los programadores creando aplicaciones más sencillas y el universo creando usuarios más estúpidos.

    Por ahora gana el universo

  16. @retlaw

    Justamente ese ejemplo que has puesto es muy bueno:

    public int valorAbsoluto(int x) {
    if(x>0)
    return x;
    else
    return -x;
    }

    Porque hay un método que no es necesario (valorAbsoluto) y porque hay dos returns. En el código se podría escribir directamente (sin necesidad de returns)

    void main (blablalbla){
    blablabla
    (x>0)? x: -x;
    blablabla
    }

    O si lo prefieres con método

    public int valorAbsoluto(int x) {
    return (x>0)? x: -x;
    }

    🙂

  17. 6. Piensas que ninguna función/método debería tener más de un return.

    Bueno, sobre los demas puedo estar mas o menos de acuerdo (creo que de patrones ya lo han defendido suficiente) pero alguien ha intentado debugear un método de 200 lineas de codigo con 20 returns intermedios!! joer… si no sabes ni donde poner el punto de interrupcion. La solucion, ir pasito a pasito desde el principio y cagarte en todo cuando de repente hace un return que no esperabas… a volver a empezar!!

    aunque no hay que ser más papista que el papa en mi opinion un metodo–>1 entrada y 1 salida… siempre con excepciones

    1. Entonces el problema es que no se sabe depurar o debugear (cada uno que coja la palabra que le guste porque no se si las dos acepciones son correctas), de que te sirve llegar al return (si solo tienes uno) si no sabes porque condiciones ha pasado para el resultado de dicho return? seria lo mismo que poner el debug despues justo de la llamada a la funcion.

  18. Aunque una función sea muy simple, apenas un return, no estoy de acuerdo con que la puedas eliminar y usar su código en el cuerpo desde el que la invoques. Es decir, que es mala idea poner a = (x>0?x:-x) en lugar de a = valorAbsoluto(x).

    Abstraerse suele ser bueno, y más con una función como esa, que seguramente llamarás más de una vez y que sería fácil escribir mal.

    Si tu comentario era para decir que la expresión condicional (?:) es mejor que la instrucción, psé, para el caso es lo mismo. Si te preocupa la eficiencia, entonces mejor un inline o las optimizaciones del compilador, que seguro lo hará mejor.

    1. Pasarse con la abstraccion es malisimo, lo primero que hay que ver es cuantas veces vas a utilizar dicha funcion por un lado o su posibilidad de repeticion y dependiendo de eso sacarlo o no a funcion independientemente del numero de lineas, ahora bien yo uso una regla cualquier codigo susceptible de poder ser repetido y que ocupe mas de 3 lineas de codigo (sin contar llaves) lo saco a funcion.

  19. @franzrogar:

    Creo que tu contraejemplo no sirve, porque usas el operador ternario que no es más que un «if» escondido… Piensa si no en como escribirias esa función en un lenguaje sin el operador ternario.

    Sería mejor algo como:

    public int valorAbsoluto(int x) {
    if (x < 0) x = -x;
    return x;
    }

    De todos modos, a veces funciones con más de un return son perfectamente admisibles… creo que la lógica dicta cuando es admisible un return o varios (no estamos hablando de mantener el código simple)???

    1. De todas formas la funcion es absurda directamente puedes poner

      a = x; sin funcion ni nada total si x es menor que cero es negativo asi queeeee jajajajajaaja.

      ahora ya fuera de coñas y funciones absurdas.

      puedes hacer perfectamente esto sin funcion ni gaitas

      if (x < 0) a = -x; else a = x;

      peeeero direis es que nsi no se ponen llaves es de mala programacion y bla bla bla.

      el crear funciones que solo vas a usar una unica vez eso si es mala programación pero no porque solo lo utilices una vez sino que a sabiendas de que solo lo vas a usar una unica vez lo saques a una funcion.

  20. Yo creo que la mayoria de los programadores tienen su software bueno y malo, al igual que los actores tienen sus pelis buenas y sus pelis malas.
    No creo que se pueda generalizar aunque si es cierto que hay malos actores tambien.

  21. Pingback: :: Verborrea Esporádica :: » 12 señales de que eres un mal programador

  22. @uno que pasaba por aqui

    Cierto, mea culpa. Es la costumbre de programar en lenguajes que tienes operador ternario :$ Tu contra-contraejemplo es el mejor puesto que sólo utilizar operadores binarios 🙂

    Bueno, sobre lo de simple… A mí (personalmente) me es más fácil leer un ternario que dos binarios 🙂

  23. «6. Piensas que ninguna función/método debería tener más de un return.»

    Esto es así por una cosa que se llama «principio de localidad» y que todos los que han estudiado programación deberían haber visto.
    Esto se hace por lo mismo que hace tiempo se quitaron los GOTOs del uso normal de los lenguajes de programación…. para hacer lo mas legible y mantenible.

    Ademas si que hace el codigo mas legible.

    1. Emmm no es correcto no se han quitado se han transformado para no pegar saltos tan gordos, pero en LotusScript se siguen usando por ejemplo porque no hay otra forma de capturar los errores, pero en el resto de lenguajes acaso no usas el exitFor? etc etc etc? pues son saltos incondicionales igualmente.

      de todos modos el GOTO se suele usar para el manejo de excepciones en muchos lenguajes y es la mejor opcion como en anterior lenguaje mencionado

  24. «Eventually» no se traduce por «eventualmente», sino por «finalmente». De hecho, ni «eventual» ni «eventually» tienen ninguna clase de relación con «eventual» y «eventualmente» en español.

    «Eventualmente» en inglés sería «possibly», o «ocasionally».

  25. Pues bueno lo de los return depende mucho de la aplicación.

    Os pongo por ejemplo dentro de un sistema de render que estoy implementando en c/c++, en lo que la velocidad es SUPER IMPORTANTE, hay que optimizar cada minimo detalle para que ocupe poca memoria, no se tiren ciclos de reloj y todo ese tipos de cosas, algunas funciones para que sean rápidas, deben tener cosa de 6-7 returns, y es simple no puedo tener variables booleanas que indiquen cuando terminar bucles porque su comprobación en cada iteración me va a gastar ciclos de reloj que bien en una función que se llama una vez cada minuto pues no pasa nada, pero en una que se llama miles de millones de veces por ejecución a lo mejor si resulta conveniente utilizar multiples returns.
    El tema de java y otros lenguajes pues me la pela, uso el que me exigen en cada momento y si tengo que hacer una aplicación primero estudiaré la plataforma y que lenguaje es más conveniente(como si debo usar asm, me da igual, el buen programador no pone pegas al lenguaje, paradigma, etc, simplemente los usa y bien usados).

    Lo del tema de localidad es falso los saltos de vuelta van a ser exactamente a la misma dirección. Depende en las condicionales, dentro de los registros internos que utilizan los predictores de saltos de cada arquitectura para hacer precargar instrucciones instrucciones(sabras que las arquitecturas actuales, al menos a las que estaras acostumbrado, porque no creo que trabajes con VLIW ni nada por el estilo, son superescalares que permiten multiple carga, lectura y ejecución de instruccion por ciclo, y cuando hay un salto predice saltar o no saltar dependiendo de los valores de los saltos anteriores, osea que no es por un return, es mas bien por un jmp o cosas por el estilo ya que un return se traduce en un ret de la llamada de un call en asm). Te garantizo que vas a tener mas penalizacion por ejemplo si en un bucle haces una comprobación del tipo
    int i;
    for( i = 0 ; i < tamanio && !fin ; ++i )
    {
    if( i == LOQUESEA )
    fin = true;
    }
    return i-1;

    que si por ejemplo haces:

    for( int i = 0 ; i < tamanio ; ++i )
    if( i==LOQUESEA)
    return i;

    Depende muchisimo de la arquitectura, la capacidad de los buferes que tengan etc, cada uno debe utilizar el return donde lo necesite.

    Respecto al uso de metodologias de modelado de sistemas software como UML, me parece totalmente correcto su uso, y la correcta documentación de un proyecto software, sino ya tendreis que trabajar en sitios donde no haya nada documentado y os cageis(mi caso por ejemplo, una aplicación asp.net con mas de 1 millon de lineas de codigo y casi sin documentar).

    Un usuario no es estupido, pero debes darle la menor libertad posible al usar tu programa.

    Una función debe ocupar lo que tenga que ocupar según las necesidades, no puedo estar continuamente haciendo llamadas a funciones en método cruciales del sistema, sería un cuello de botella. Pero por ejemplo supongamos un parser de ficheros, que lo llamas una vez cada mucho tiempo, pues si queda mas legible si está bien organizado.

    Quien no haya usado el copy & paste que tire la primera piedra.

  26. El post me ha hecho reir bastante. En mi empresa todos (Yo incluido, y demasiado incluido) tenemos un serio problema con el punto 2.
    Pero estoy muy deacuerdo con Blaxter.
    Returns 1 ¡¡¡POR DIOS!!!
    Cuando a mi me ensañoron patrones, lo primero que me digeron antes de enseñarme ninguno, ni siquiera strategy (q ese de verdad que en cualquier lado hace bien) fue: «Cuando tienes en la mano un martillo, todo parece un clavo, cuidado con los patrones»
    y sobre el rendimiento. Si eres programador de java, lo que verdaderamente importa son dos cosas:
    La VM le encanta hacer hebras, no hagas tu más.
    La memoria se va en un santiamen. No piense, «va esto va a correr en una maquina de 2GB solo, no tengo problema de control de referencias ya vendra GC» No, usa null que no cuesta.
    Un saludo a todos.

  27. Evidentemente este es un nota más acerca de un tema como la programación escrita por alguien que simplemente pocas veces estuvo envuelto en un desarrollo serio de software, lo digo por la nota original no por la traducción. 😉

    Sencillamente cualquiera dudo que quien haya escrito este entrada sea programador o mucho menos.

    Saludos y muy bueno el blog,… en general!

  28. Lo primero muy bueno el post.

    Respecto al número de returns me parece menos legible continuar una función hasta donde se encuentra el return que poner varios return si se pueden dar circunstancias que hagan posible que el resultado se obtenga antes. Esto es especialmente en lenguajes debilmente tipados donde incluso lo que se devuelva puede no tener el mismo tipo.

    Si una función tiene 200 líneas ya es difícil hacerle debug; el hecho de que tenga 20 returns implica que hay 20 formas de terminar diferentes en mi opinión es mejor retornar al obtener el resultado que continuar 140 lineas de código más para poder salir por el return único.

    En general cuando se intentan forzar las cosas para que entren en algo (Java, patrones, métodos cortos, un único return por método,…) no se están haciendo las cosas de la mejor manera posible.

    Python está muy bien y sirve para (casi) todo lo que sirve Java y muchas otras. Aplicaciones web (Django, Turbogears, Plone,…), aplicaciones de escritorio (wxPython, PyQT, PyGTK,…), aplicaciones de consola o administración, etc. La NASA utiliza Plone en http://mars.telascience.org/home. Si tuviera que elegir un único lenguaje sería python o ruby; pero estoy de acuerdo en que hay otros muchos que resuelven temas concretos mejor que estos.

  29. Notable la frase

    @Raistlin Majere

    Quien no haya usado el copy & paste que tire la primera piedra.

    XD
    jajajaja

    yo creo que estas 12 señales son un poco parcelarias, onda tadas son rebatibles y su uso en exclusivo, onda todo con patrones, todos con un return y toas esas cosas, estan mal. Cada cosa en su medida justa, sin irse al chancho

  30. Paulus, es un programador que trabaja para MySQL AB, que para los que no lo sepan y no sean capaces de adivinarlo por el nombre, son los creadores de MySQL.

    MySQL AB no es ninguna broma. Es una de las mayores empresas relacionadas con el software libre.

  31. Juas aquí la peña va un poco de guay, que es la ostia, que programa devolviendo los returns que se debe, uml’s blah blah. Llevo ya 3 años comiendo mierda de proyectos: grandes, pequeños… y todo degenera que da gusto. Proyectos con uml, diagramas… que se ponían rápidamente para quedar chupi: 100 hojas, 200… y al leerlos veías que estaba hueco , no aportaban información, mención aparte para nuestro analista que estaba medio loco. Proyectos que en su dia se hicieron con herramientas case y luego se dejaron a su suerte en plan 300 clases y cada una con 20 lineas jaja os juro que esto es verdad. Bucles anidados que han ido cambiando y cambiando (meteme este proveedor, este proveedor hazmelo así, esto es un proveedor pero que funcione como cliente). Documentacon siempre pero siempre desactualizada. Así que una razón más importantes que todas esas es que te fuerzan a ser mal programador porque el código que te comes no hay por donde cogerlo, te meten prisa y así no se puede, esa es en parte una realidad si no de todos si de muchos programadores. Así que muchos de esos puntos que se enumeran sólo valdran para proyectos desde cero y cuando se vaya mal de tiempo (como suele ser)… a degenerar jeje.
    Un punto más: programa sencillo, que el programador más lerdo pueda entenderlo, no te flipes con los algoritmos más vale 50 lineas legibles que 20 ilegibles (sobre todo si peta algo y hay que depurarlo).

    Me sorprende que aquí nadie haya expuesto el factor tiempo que hace estragos en el código y en la gente.

  32. Estoy en desacuerdo con la mayoría de planteamientos. Sin embargo de eso se trata, de debatir sobre lo que es aceptable o no, tratando de estar siempre abierto a la crítica y autocrítica.

    Hay una diferencia entre programar y diseñar sistemas. Es lógico que esto lo escribió alguién que se dedica únicamente a programar.

    Cuando se desarrollan sistemas grandes, el diseño es vital para garantizar la calidad del software. Un error frecuente que comenten muchos programadores es comenzar a escribir código sin primero hacer un mapa de qué es lo que hay que programar, cómo se relacionarán las clases o funciones, etc.

    Luego hay un término que parece que cada vez es menos frecuente en la jerga de los nuevos programadores: Estándares. Este término ahora ha tomado una forma más abstracta y más robusta con el aparecimiento de los llamados patrones. Coincido en que quienes a veces creemos en la adopción de patrones, estándares y convenciones tendemos a aplicarlos de manera obsesiva. Sin embargo, el otro extremo, y es el que puede preverse genere el texto que ahora comentamos es no seguir ningún tipo de convención, estándar o patrón, produciendo una cantidad de código excesivo, ineficiente e ilegible.

    Sobre el tema de tiempo del CPU, estoy de acuerdo es en que no se puede pasar una enternidad «optimizando» un código que probablemente no represente una cantidad significativa de tiempo.

    Sin embargo, se corre el riesgo de que se piense que nosotros no debemos preocuparnos por eso, porque no estamos resolviendo un problema para la NASA. El tiempo del CPU es importante, sino ¿qué haría si en un bucle hago 300 mil iteraciones en lugar de las 300 necesarias?, ¿no retrasa esto el tiempo de respuesta del software?, sería torpe no preocuparme por eso.

    Lo estructural del código depende del estilo de programación de cada quién. Sin embargo, la práctica nos demuestra que entre más estructurado es un programa, más sencillo se vuelve adoptarlo y mantenerlo.

    Saludos.

  33. @Zootropo

    Si yo perteneciera a MySQL AB y me encuentro con esta persona sinceramente no se si me gustaría trabajar en un proyecto con él, sin embargo como en su pagina lo indica:

    «I’m a software engineer working full time on MySQL.»

    Asi que con esto queda todo dicho!

  34. Ok por Blaster

    Empecé allá por el 80, programando en papel, para luego llevarlo a fichas perforadas y darlo a ejecución. Tardaban los resultados a veces más de una semana. Por tanto el código se pulía lo que fuese necesario, y esta labor era la que más aleccionaba sobre la forma de trabajar de uno mismo. No quiero decir que haya que volver a todo eso, xD, solo ejemplarizo. Cuando empezamos a hacer código sobre pantalla, la calidad empezó a variar en función de la rapidez, a mayor rapidez, menor calidad, aunque no fuese una función inversa ni lineal. Con el tiempo empezaron a llegar entornos orientados a eventos, visuales etc. etc., vaya ya sabeis la evolución, y el mayor defecto ha sido el que las nuevas generaciones no hayan pasado por lenguajes primigenios, sino que directamente han ido a cosas modernas. En el más clásico de los casos han ido a programar en C a pelo como si fuera ensamblador, eludiendo metodologías de cualquier tipo, o al menos reduciendo a casi nada antiguos paradigmas. Éstos, evidentemente pueden darse como pasados en casos, pero hacen que la expereriencia no sea al 100%, y que en la actualidad, el mejor ejemplo del desastre modernista (ojo, no es por ser reaccionario, que conste, es por ser purista) sea la mierda del Windows,extendida al 100% del mundo salvo en casos de trincheras y maquis. Es el mejor ejemplo de cómo se hacen las cosas hoy en día con respecto a todo. Rápidas, bonitas, inútiles a veces, retóricas, inseguras, cacas, molonas, y sobre todo …venden. Pero fallan a mogollón.

  35. Las afirmaciones son reguleras, pero hay que diferenciar. Una cosa es «programar» y otra «desarrollar software»… a nivel de programación, teórica, el tema de los returns, lo de los patrones, lo de las líneas de código… tiene sentido… pero cuando se está desarrollando software, hay que alcanzar un equilibrio entre lo que dicen los libros de texto sobre «the art of programming», y la realidad del día a día, que nos lleva a hacer chapuzas y a sacrificar TODAS las recomendaciones académicas de una buena programación. Los patrones, por ejemplo, en ocasiones son MUY buenos aliados incluso desarrollando software comercial, pero efectivamente, aplicarlos siempre a hierro es muy mala opción, porque es matar moscas a cañonazos…

  36. Creo que pudiste hablar de aspecto mas relevantes que se pueden entender como «señales» de técnicas erróneas de programación.
    De esto se podría hablar mucho, pero se debe tener en cuenta que ante todo existe reglas de programación importantes (que incluso no se comentan en muchas academias) y que no se estiman por simple ignorancia.
    No solo se trata de herramientas especificas… como hacen los Técnicos de paquetes…
    Entre otras cosas se trata de escoger las herramientas que te permitan darle una solución elegante a tu problema y que te permita hacer de tu programa una solución, robusta, escalable.. etc.

    Por eso, invito a todos los que de alguna forma empiezan (como yo) vean mas allá del «Hello world» típico de los libros y estudien código libre y se darán cuenta como diría Morfeo «Que tan grande es el hoyo».

    Saludos.

  37. No comparto lo de UML. Un programa es bueno si responde a un buen modelo, al programar solo hay que hacer lo que dice el modelo. El modelo define un buen programa y para eso UML (q tampoco es la panacea) proporciona herramientas para describir completamente el funcionamiento del software. Si eres capaz de programar esa descripcion al pie de la letra eres un buen programador sino, simplemente estas haciendo las cosas mal.

  38. Me parece que en tu infancia de programador algun Arquitecto de software te cometio algun abuso indescriptible y les traes contra desde entonces.

    Si piensas que el codigo no son dibujitos que me dices de los sistemas en LabView?

    O es que acaso ya te remplazaron por una herramienta CASE(que aun estan en pañales por cierto)?

    Parece que java tambien te esta dejando sin proyectos y le declaraste la jihad. La filososfia de java es en efecto esa y no le veo nada de malo: «Aprendelo una vez y usalo donde quieras», claro que ante cosas como Ruby me quito el sombrero pero hasta eso ya existe Ruby sobre java. Que quieras aprender N-mil maneras de hacer un hola mundo como te daras cuenta no es la gran cosa a la hora de buscar proyectos.

    El resto de tus puntos me parecen atinados, cuestion de ir adquiriendo buenas practicas con la experiencia.

  39. Nation84

    • Yo no soy el autor. Relee el primer párrafo.
    • Nadie está criticando a UML. Relee ese punto.
    • Java no es la respuesta a todas las preguntas. Y te lo dice alguien que probablemente sea el lenguaje que más ha utilizado
  40. Esto del punto once es una gran estupidez:

    «Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.»

    ¿Quién escribió eso?

    Entonces uno puede extrapolar este concepto y decir:

    Los planos de un edificio no son el diseño, y nunca serán el diseño, para eso están los ladrillos, columnas, etc.

  41. Sorry me falto aclarar que obiamente me referia al autor de los puntos, tal como escribi mi comentario anterior se podria malinterpretar. Muy buen blog por cierto 🙂

Responder a Cristobal Cancelar respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.