El buen programador

Cualquier idiota puede escribir código que un ordenador pueda entender. Los buenos programadores escriben código que las personas puedan entender.

— Martin Fowler

Comentarios
  1. Martin Fowler es el autor de “Refactoring: Improving the Design of Existing Code” y “UML Distilled”, entre otros, grandes clásicos de los que ya hablamos en 10 libros míticos sobre programación que todo desarrollador debería leer.

    Responder

  2. yo tengo mis dudas de esta afirmación.

    Responder

    • ¿Por qué? ¿no crees que el que el código sea fácil de entender es una de las cosas más importantes a tener en cuenta a la hora de programar?

      No solo para facilitar el trabajo al resto de personas que tengan que leer tu código, sino para facilitarte la vida a ti mismo. Si tienes que volver a leer tu código para hacer algún cambio dentro de 3 meses, prácticamente estarás en la misma situación que si estuvieras leyendo el código de un extraño.

      Ya lo dijo Niklaus Wirth en su día: “Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration”

      Responder

      • EgoPL
      • basicamente porque no todo el mundo esta en la capacidad para leer cualquier tipo de código, por muy ordenado, documentado y bien escrito que este.

        Responder

        • David

          No dice que programes para los idiotas. Dice que programes para las personas.

          Responder

          • imagina que eres un programador super senior chorrocientos años de experiencia en java, bla bla bla, te toca un pelmazo de jefe que pone a trabajar a tu lado a un tipo que lleva 6 meses que hizo un modulo de programación, realmente crees que va a entender tu código, por muy bien escrito que este? lo dudo, pero pues para opiniones, colores.

      • Los verdaderos programadores no documentan. Si fue difícil de escribir, entonces debe ser difícil de entender!. xD

        Responder

      • Es cierto, es muy frecuente que hoy escribes codigo que en una semana no sabes para que sirve.

        Responder

    • Fox

      ¿Por qué ese chaval de 6 meses no iba a poder entenderlo? Yo ni siquiera he terminado mi módulo y me considero buen programador e incluso escribo artículos de ello…

      Responder

  3. Alex

    Exacto, la idea no es escribir un código complejo y desordenado y sin documentar, ademas si una persona no lo entiende es difícil que una maquina lo entienda.

    Responder

  4. Ajaja no si uno programa en LISP
    😉

    Responder

  5. e… este ordenado, con montón de comentarios, pero cualquier persona lo entendería, tenga 6 meses o 800 años en java, el de 6 meses va a entenderlo si tiene lo mas vasico en el lenguaje!
    el tema es formar diferentes funciones del programa, y que cualquiera lo entienda!, si a alguien le pongo esto:

    // multiplicacion
    resultado = dato1 * dato2;
    System.out.println(dato1 + ” * ” + dato2 + ” = ” + resultado);

    que va a entender?

    tengo 4 días en java (si me equivoco corrijanme xD!

    Responder

  6. En realidad si te equivocaste…

    Basico se escribe con B

    🙂

    Responder

    • EgoPL

      En realidad si te equivocaste…

      Basico se escribe así. Básico, como vosotros. 😛

      Responder

    • byJonyB

      Qué malos sois, xD.

      by JonyB

      Responder

  7. Muy cierto.

    Responder

  8. Muy cierto, se gana un montón de tiempo con el mero de hecho de incluir unos comentarios al código y de mantener una estructura clara. Un sabio el Fowler éste 🙂

    Responder

  9. Yo diría que esa afirmación es muy cierta, se ahorra mucho tiempo simplificando el código, para que cualquier ser a base de carbono lo entienda.
    El ejemplo mas complejo que encuentro es el ADN, la evolución, codifico nuestras instrucciones mas básicas de tal forma que ahora nosotros comenzamos a descifrarlo.
    Así que no hay que subestimar el poder de un código simple y entendible.

    Responder

  10. Mensa13

    Discrepo en cierta parte. Vale que un código legible es más fácil de ampliar, extenderse entre la gente y evita quebraderos de cabeza.

    Pero un buen programador también tiene que mirar la efectividad de un código. Prefiero mil veces un código rápido que uno legible.

    Responder

    • Una cosa no tiene por qué estar reñida con la otra.

      Pero es que además, como dijo el mismísimo Donald Knuth, “Premature optimization is the root of all evil”.

      Responder

      • byJonyB

        Zootropo, muy buena esa frase también. Creo que debería leerme algún libro que expusiste el otro día, xD.

        by JonyB

        Responder

  11. Mensa13

    Muchas veces las operaciones a nivel de bit, o la utilización de postincremento de punteros a la hora de recorrer arrays están mal vistas desde el punto de la legibilidad de un código.

    A mi opinión un código más efectivo pero bien comentado es la clave para un buen programador.

    Responder

    • kurt

      Pues yo prefiero un código “legible” a uno “rápido”, porque el primero inevitablemente lleva muchas veces al segundo, pero no a la inversa.

      Por legible me refiero siguiendo técnicas de software como patrones, y demás.

      Responder

  12. Miguel-Palacio

    Totalmente de acuerdo con esta afirmación. En el trabajo me toca tratar con códigos que no están para nada comentados…no los entiende nadie, de hecho, solo una persona en la empresa entiende el código, por lo que si uno tiene problemas siempre toca acudir a él (si este hombre se muere, se quiebra la empresa).

    Yo también creo firmemente que el código debe estar ordenado, bien tabulado y muy bien comentado, a veces hasta el autor se le olvida lo que hizo (me ha pasado xD, por eso ahora siempre comento lo que hago).

    Responder

  13. Ditirambo

    Es importante ser ordenado para programar,yo siempre voy nombrando a las variables por orden alfabético.

    Responder

  14. jorge

    pues no lo creo asi, tengo vecinos , que aunque les ponga comentarios no lo entendieran…

    Responder

  15. hzx

    seguramente martin era un poco limitado

    Responder

    • David

      Macho ¡estas hablando de uno de los tíos más respetados de la profesión!

      Responder

  16. A buen programador, pocos comandos bastan 😉

    Responder

  17. byJonyB

    Yo también estoy de acuerdo.

    Recuerdo cuando tuve que hacer prácticas para poder terminar mi grado superior, tuve que hacer un programa desde 0 para un hospital. Pues bien, como pidieron mucho y lo querían rápido, ni documenté ni nada. Al de un mes ya no sabía ni lo que había hecho el primer día, xD.

    Me tiré un par de semanas para dejarlo “legible”…

    by JonyB

    Responder

  18. Pienso que es una cuestión de comodidad, si tu código no va a ser leído por nadie más y te sientes feliz escribiendo algoritmos crípticos (por lo enredado de tu estilo), ¡pues que bien! Eres un programador feliz a quien nadie podrá entender jamás, pero a quien no le hace falta que lo entiendan.

    Por el contrario, si eres un desarrollador que trabaja en equipo, es vital y de caracter obligatorio documentar tu código. No tiene que ver con el ejemplo que diera antes Kalith, tiene que ver conque tus coequiperos puedan dilucidar fácilmente lo que has escrito y más aún, que ese código sea entendible en el tiempo.

    ¿A cuántos no les ha ocurrido que deben leerse listados gigantezcos de código escritos por si mismos porque no recuerdan que hicieron?

    No digo que comenten una línea como: c = a + b

    Me refiero a las líneas que realmente ameriten ser comentadas. Ya sea por la dificultad en la sintaxis usada o ya sea por lo enredado de sus orígenes dentro del código escrito.

    De igual manera debe evitarse la escritura de código críptico o el uso de nombres de variables que nada indiquen sobre el tipo de datos que almacenan o el dato que almacenan.

    Por ejemplo, a continuación les muestro varias maneras de hacer lo mismo en VFP (lenguaje derivado de XBase):

    function StrZero( iNum, iZeros )
    local sZeros

    && Validación de los parámetros
    if Vartype( iNum ) “N” or Vartype( iZeros ) “N”
    sZeros = “”
    else
    && Determina la cantidad real de ceros a la izquierda
    iZeros = iZeros – Len( Alltrim( Str( iNum ) ) )
    && Creación del valor de retorno
    sZeros = Replicate( “0”, iZeros ) + Alltrim( Str( iNum ) )
    endif
    return( sZeros )

    —————————
    Luego la misma función, algo simplificada y sin ningún tipo de comentarios:
    function StrZero( iNum, iZeros )
    return( PadL( Alltrim( Str( iNum ) ), iZeros, “0” ) )

    —————————
    Ahora algo más minimalista y por supuesto, sin comentarios:
    function StrZero( iNum, iZeros )
    return PadL(iNum, iZeros,”0″)

    —————————
    Por último, una función, cuya críptico código es dificilmente entendible por alguien que no conozca el lenguaje:

    varieble = RightC( “0000000000” + Alltrim( Str( Vnum ) ), 10 )

    En fin, no espero crear polémica, sólo hacer ver lo importante de los comentarios/documentación en el código.

    Responder

  19. sin mencionar comentar el codigo e identar ja

    Responder

  20. BladeRunner

    El buen código debería ser autocomentado. Es decir, usar nombres de variables, funciones, métodos, etc. que sean autodescriptivos, que den una idea de su fin o propósito.

    Aparte no vale poner comentarios para cada línea cuando es evidente su finalidad. Por ejemplo, he visto comentarios de este tipo:

    a = b + c; // Asignar la suma de “b” y “c” a “a”

    Saludos

    Responder

  21. Miguel BR

    Zootropo, escribe uno sobre como se depura el codigo. Pongo ejemplos con programacion para web, porque es dificil tener un depurador de linea por linea. Aunque tambien aplica creo a los programa que son para tiempo real y una depuración “paso a paso” no muestra valores reales.

    Me refiero a que por ejemplo en javascript pongo console.log(“foo(1234, ‘div_tr003’)”) para indicar que llegue a la funcion foo con los parametros 1234 (que es el id del registro en la base de datos) y ‘div_tr003’ que el div que debo actualizar con los datos que voy a llamar por ajax.

    O del lado del servidor tengo una funcion llamada alLog(string,operador, nivel) que llamo (estoy empezando con este metodo hace 1 semana)

    1.- alLog(“entro a funcion foo1”, “>=”, dbgMinimo)
    2.- alLog(“query = ” & server.form, “>=”, dbgDet)
    3.- alLog(“Error al salir de la funcion foo1”, “=”, dbgNor)
    3.- alLog(“programa finiza con ” & salida, “>=”, dbgTodo)

    el 1er parametro es lo que voy a mostrar
    el 2do con que operador a voy a revisar
    el 3ro el nivel donde decido si lo muestro

    el 1, como es dbgMinimo solo lo muestro cuando quiero mostrar todo. sobre todo cuando entra y sale de una funcion
    el 2, con dbgDet cuando quiero ver con que se esta ejecutando una funcion
    el 3, con dbgNor cuando solo quiero saber si hubo error y en donde
    el 4, con dbgTodo lo uso para saber solo en que momento inicio el programa, una funcion intermedia y cual fue el resultado final sin saber donde fallo.

    Todo esto lo grabo en una BD.

    Tengo duda de como hacen otras personas.

    Responder

  22. javichi

    Siempre desde el punto de vista de un consultor y no de un programador

    Responder

  23. […] (Vía Mundo Geek) […]

    Responder

  24. Depende desde como se mire?

    Responder

  25. Anónimo

    Una cosa es que el ordenador entienda el código, y otro que esté bien escrito

    Responder

  26. eso es siempre en cuando trabajes en una empresa, o sea que otros van a ver tu code ^^!, jaja vas a hacerlo bien descifrable para que otros roben tu arte ^^! o será por las puras que se creo el MD5

    Responder

  27. Si buscas resultados distintos, no hagas siempre lo mismo :), cada uno programa como quiere, con tal que sea rápido y eficaz para un ordenador.

    Responder

  28. […] Mundo Geek) Comparte este post: This work, unless otherwise expressly stated, is licensed under a Creative […]

    Responder

  29. Jorge luis

    Escribir un programa que empleé una PILA y que evalúe los paréntesis de una expresión matemática e imprima si está bien escrita o no.
    Ejemplo 1:
    Escriba la expresión: (a+b)
    La expresión es válida.
    Ejemplo 2:
    Escriba la expresión: a+b)
    La expresión no es válida.

    Responder

  30. Depende como se mire. Mejor que un ordenador lo interprete más rápido a costa de que un humano tarde más en leerlo. No?

    Responder

  31. Completamente de acuerdo 😉

    Responder

Deja un comentario