47 comentarios en «El buen programador»

    1. ¿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»

          1. 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.

    2. ¿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…

  1. 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.

  2. 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!

  3. 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 🙂

  4. 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.

  5. 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.

  6. 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.

    1. 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.

  7. 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).

  8. 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

  9. 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.

  10. 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

  11. 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.

  12. Pingback: La importancia de la estructuración « Blog SRCA

  13. 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

  14. Pingback: La importancia de la estructuración | Elec2.es

  15. 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.

Deja un comentario

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