¿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»
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.
¿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…
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.
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:
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 🙂
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.
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.
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).
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.
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:
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:
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.
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
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.
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.
yo tengo mis dudas de esta afirmación.
¿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
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.
No dice que programes para los idiotas. Dice que programes para las personas.
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
Es cierto, es muy frecuente que hoy escribes codigo que en una semana no sabes para que sirve.
¿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…
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.
Ajaja no si uno programa en LISP
😉
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!
En realidad si te equivocaste…
Basico se escribe con B
🙂
En realidad si te equivocaste…
Basico se escribe así. Básico, como vosotros. 😛
La verdad es que necesitabas usar esta expresión: XD en lugar de :P.
Qué malos sois, xD.
by JonyB
Muy cierto.
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 🙂
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.
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.
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».
Zootropo, muy buena esa frase también. Creo que debería leerme algún libro que expusiste el otro día, xD.
by JonyB
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.
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.
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).
Es importante ser ordenado para programar,yo siempre voy nombrando a las variables por orden alfabético.
pues no lo creo asi, tengo vecinos , que aunque les ponga comentarios no lo entendieran…
seguramente martin era un poco limitado
Macho ¡estas hablando de uno de los tíos más respetados de la profesión!
A buen programador, pocos comandos bastan 😉
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
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.
sin mencionar comentar el codigo e identar ja
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
Totalmente de acuerdo.
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.
Siempre desde el punto de vista de un consultor y no de un programador
Pingback: La importancia de la estructuración « Blog SRCA
Depende desde como se mire?
Una cosa es que el ordenador entienda el código, y otro que esté bien escrito
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
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.
Pingback: La importancia de la estructuración | Elec2.es
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.
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?
Completamente de acuerdo 😉