Buen código, mal código

Leí este artículo hace unos días, y me dio la idea de escribir al respecto la primera entrada de este blog.

Como se menciona en el artículo referido, es fácil decir que un código es malo cuando está hecho de una forma que no es la que uno acostumbra. Entender código ajeno toma tiempo, y hay veces en que mejor optamos por rehacer las cosas a nuestra manera en vez de tratar de comprender qué pensó (o de cuál fumó) el programador para sacar un código así. Claro que si vemos un código complicado, que no entendemos pero que sabemos que funciona, es mejor no reinventar la rueda y dejarlo así. Las 2 caras de la moneda.

Está de más mencionar que cada quien tiene su estilo de programación. Ciertamente hay muchas maneras de resolver un problema, aunque hay ocasiones en que solo existe una óptima. Como programador, lo primero es que el programa funcione, que haga lo que tiene que hacer, y después uno se dedica a “ponerle florecitas”. NUNCA olvidar las pruebas, siempre enfadosas, indeseables, pero desafortunadamente necesarias.

Recuerdo que uno de mis primeros programas, cuando apenas aprendía el arte en 2do. semestre de la universidad (porque era de los que me daba miedo prender una computadora, creía en el programa-ouija Eilsa, etc.), fue calcular el factorial de un número. Olviden la función recursiva (sin querer decir que es el mejor algoritmo): hice todo con un while y haciendo brincos de 2 en 2. El programa funcionaba; el algoritmo lo había pensado yo; todos felices. Hasta después supe que había más y mejores formas de resolverlo. Entonces, ¿mi código era malo?

Tuve un muy buen maestro de programación. Adopté su estilo, y debido a eso, no me cuesta trabajo entender algún programa que él haya hecho. Pero a lo largo de mi vida laboral y estudiantil, son pocas las veces que he tenido que revisar o corregir código ajeno, y cuando lo he hecho, trato de no juzgarlo, aunque sí me quedo pensando si hay una mejor manera de solucionar el problema.

¿Qué es entonces lo que criticamos cuando decimos que un código es malo?

Nadie nace sabiendo, pero hay límites para todo. Por ejemplo, si vamos a trabajar con una serie de datos, los cuales no sabemos la cantidad, creo que está de más decir que necesitamos algo dinámico como:

 

public class X {

  private List<Integer> somelist = new LinkedList<Integer>();

 ...
}

en vez de algo estático que nos pone un límite que no sabemos si sea correcto (como en este caso, 100):

public class X {

  public int [] somearray = new int[100];

  ...
}

Cuando veo un código de esta naturaleza, lo primero que me viene a la mente es que es de alguien que apenas está comenzando a estudiar programación ( y sigo recordando mi programita del factorial 😛 ), o alguien que ha trabajado durante mucho tiempo en un lenguaje donde no se pueden crear cosas dinámicamente y apenas está entrando en uno donde sí es posible. El último lugar donde pienso encontrar algo como lo de arriba es en una empresa de desarrollo de software, y en las que he estado, siempre me he encontrado con algo similar.

No digo que mi código es la quinta maravilla, porque tengo errores y conozco gente que programa mejor que yo. Sin embargo, creo que lo que criticamos al ver un código “malo” no es en sí el algoritmo (aunque si para ordenar una cantidad considerable de números alguien usa bubblesort en vez de quicksort o algún otro método rápido, también puede ser objeto de críticas), sino el conocimiento de esa persona en ese lenguaje de programación. La forma de resolver el problema puede estar bien, pero el lenguaje puede darnos herramientas para hacerlo más rápido, más eficiente o simplemente para no quebrarnos la cabeza programando cosas que ya están hechas.

¿Opiniones?

System.exit(0);

0 Replies to “Buen código, mal código”

  1. Pues en algunas cosas que dices difiero, tengo experiencia dando mantenimiento a código y creando código nuevo, sin embargo si te topas con cada metida de pata que para que te cuento, con decirte que una vez me tope con código que nadie entendía, tenía mi edad así que la persona que lo codificó ya ni trabajaba n la empresa, pero en el comentario que tenía el código decía “lo puse así por que tal persona me dijo que así funcionaba” X(

    Ahi ni como ayudarle al fulano

    Otro comentario, por experiencia se que lo malo del código es directamente proporcional al estress del programador, es decir, si t estan apurando es lógico q saques un código mas malo…

    Saludos…

  2. Creo yo que uno de los mayores enemigos de un programador es el orgullo.

    Hay veces en que el código está de “mírame pero no me toques” donde con una maraña de instrucciones, callbacks, iteraciones y demás, se logra el resultado buscado.

    Cuando se trata de un proyecto personal, ahí no hay bronca porque uno puede hacer lo que le venga en gana y probar mejores soluciones, pero cuando hablamos de un ambiente empresarial ahí ya hablamos de costo/tiempo.

    Hay veces en que no puede andar “experimentando” o “explorando” nuevas formas en plena etapa de desarrollo (claro está, dependiendo de la metodología que usen); lo que le importa es que funcione y funcione bien.

    Yo en proyectos personales, normalmente me tardo más de lo que quisiera tardarme, pero es porque busco la mejor manera de resolver problemas y no querer hacer “chambonadas” 😛

    Ningún código es el santo grial y jamás habrá uno como tal. Cada programador tiene enfoques diferentes y, dependiendo de la experiencia (principal factor, pienso yo), es la forma en que afrontan problemas con soluciones integrales (ya ya, demasiada cháchara empresarial jaja).

    Los buenos programadores no nacen, se forman. 🙂

  3. Si, tienes razón. Cada programa es tan distinto como el autor del mismo.

    Sólo es cuestión de práctica el que uno haga programas que usen menos líneas de código, que sea eficiente y que además se entienda. (^-^)

    Ah! Y si además lo podemos hacer/entender en varios lenguajes de programación… eso sería mejor XD

  4. Yo a veces me sorprendo de mis colegas del trabajo, como hacen de algo simple un codigo complejo, pero ahi que ser tolerante si uno tiene más años de experiencia y el colega apenas esta empezando, por que a mi me han sorprendido dandole solución a un problema que yo le di muchas vueltas, lo mejor es mantener el respeto nunca se sabe cuando ellos te daran la sorpresa 🙂

  5. Depende de la aplicación, el segundo ejemplo puede ser de un programa de interfaz de un sensor de agua, el cual usa 100 registros por lectura, etc…

    En caso de listas de nombres, clientes, pagos, palabras y cosas parecidas es mejor el primer ejemplo, porque no se determina en un principio el tamaño que puede alcanzar.

  6. Olviden la función recursiva (sin querer decir que es el mejor algoritmo)

    Discrepo(diría un conocido), de hecho es el peor algoritmo, esa función genera un crecimiento exponencial.

    Lec 8 | MIT 6.00 Introduction to Computer Science and Programming, Fall 2008

    lo bueno empieza en minuto 22 y el ejemplo de crecimiento minuto 27

    1. Andres. Creo que esta demas decir que el algoritmos es de lo peor, creo que manuel fue claro al decir que estaba en sus comienzos en el arte de la programación y tambien dijo que era su primer programa.

  7. No hay como programar con la máxima concentración y estar inspirado, recuerdan la película de Antithrust? ése sería el escenario perfecto para que la creatividad fluya. Pero bueh.
    Mi error hasta ahora es ser un ratón de biblioteca (Programo en C#) que nada más lee y lee pero nunca practica. Creo que eso hace que mi código (a mi parecer) sea malo. 🙂

    PD. sé que ésta entrada tiene mucho tiempo, pero quería comentar para ver cómo se sentía.

  8. Bueno, en mi opinion creo que muchas de las formas de programar depende en si de lo que comentas y los usuarios aqui comentan, realmente ahora si que aqui aplica eso de “aprender de los errores te hace madurar” pero realmnete hay gente que ni asi lo hace XP

Leave a Reply to GabrielAispuro Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.