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.
Etiquetas: programacion
Ahorra 50 dólares en tu alojamiento web
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
¡Genial! Creo que se ma aplica el 33 y el 11
… Habrá que mejorar.
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.
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.
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
), 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 
)
Yo discrepo en bastantes puntos, quizá sea un pésimo programador, pero no me hará cambiar de opinión.
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.
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.
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.
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.
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.
@Blaxter re punteros: el punto de Cristóbal es, precisamente, que un mal programador no va a querer saber nada sobre punteros.
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
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
Yo discrepo en algún punto.
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.
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.
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.
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.
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
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.
Me parece a mi o a los comentarios les falta:
sentidoDelHumor = true;
siempre programo con la idea de "keep it simple", pero a la vez siempre he pensado eso de los usuarios
La verdad es que si que hay algunos usuarios que se las traen…
[...] 12 señales de que eres un mal programadormundogeek.net/archivos/2007/11/24/12-senales-de-que-eres-un-… por Zootropo hace pocos segundos [...]
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
Suscribo la opinión de Blaxter punto por punto, incluidas las conclusiones acerca del autor.
Eso me recuerda a una cita, que ahora mismo no se de quién es y que decía algo así como:
@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;
}
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
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.
@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)???
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.
[...] en Barrapunto, a su vez en mundogeek y a su vez en digg [...]
@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
"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.
Me da la impresión que quien escribió esto sólo trabaja en sus propios proyectos.
Echa un vistazo al enlace que puse antes, Joan:
Single Function Exit Point
"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".
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.
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.
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!
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.
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
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.
¿Hay algún programador que no se considere perfecto?
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.
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.
@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!
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.
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…
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.
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.
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.
Nation84
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.
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
La mayoría son del tipo "No hay que pasarse"
Salvo quizá la 1) Quedarse con un sólo lenguaje, la 7) que los usuarios son estúpidos y 12) Tu programa borra datos importantes.
Es lo que pasa cuando uno confunde las buenas prácticas con normas divinas. Lo que ha sacado es una lista de donde se cae más habitualmente por exceso.
Por ejemplo los programadores recien salidos caen a menudo en 5) lo de ahorrar ciclos de CPU, se pasan dos días en ganar un 0.1% de velocidad, cuando el programa debería estar la semana pasada, y para colmo hacen un código ilegible.
La 2), 3) y 4) ("enterprisey", funciones de no más de 30 líneas y patrones "per tuti") son más propios de gente que lleva mucho tiempo metido en la empresa y se ha hecho a unas prácticas rutinarias.
Y por cierto, en el 1) Quedarse con un sólo lenguaje, también se puede caer en el exceso en sentido contrario. Dominar un lenguaje y entorno de trabajo para trabajar con soltura cuesta tiempo (recordar la sintáxis, las funciones que hay para cada cosa etc), tampoco es buena idea que un proyecto tenga 27 lenguajes, ni que un programador salte de una a otro continuamente teniendo que repasar y mirar la ayuda cada dos líneas.
He leido todo el post, todos los comentarios, sobre el uml no comento nada, estoy deacuerdo con lo que se ha dicho mil veces. Sobre el rendimiento decir que si no ves la forma mas optima de hacer algo es por falta de atencion o que en tal caso la optimizacion necesita de mucho tiempo y es imprescindible, digase por ejemplo en un software como photoshop.
Quien conoce en mayor o menor medida muchos lenguajes sabe perfectamente que java no esta hecho para todo, el lenguaje que mas se aproxima a eso es c++ y tampoco puede cubrir todo, si os gusta python probad perl, prefiero entender en 20 lineas de cualquier lenguaje que una sola de perl que hagan lo mismo, los lenguajes de scripts estan para lo que estan, no hay sistemas operativos escritos en java ni en python.
Patrones, si por favor hay mas gente en el mundo que necesita saber que es cada cosa, claro que todo sin abusar, los return uno o varios me es indiferente, normalmente uso uno, pero si en las busquedas dentro de bucles pongo otro, simplifica y la simplificacion siempre ayuda.
Si en algun metodo o funcion necesitas mas de 30 lineas es o bien porque no lo estas programando bien o esta mal diseñado, desde que los gotos desaparecieron el mundo es mejor, el dia en el que no exista metodos de mas de 30 o 40 lineas el mundo sera mas feliz, entonces dara igual el numero de return.
Sobre el 12 como coño se programa algo que borra todo?, desde mi punto de vista que un programa borre un fichero es como pensar en un cirujano, tienes que estar muy seguro de lo que se esta haciendo, si no, es mejor que lo haga otro.
Sobre los usuarios, puede que tu software no tenga usuarios inutiles, pero entonces seran malintencionados, y es mejor limitar muy mucho lo que pueden hacer.
Yo me siento orgulloso cuando consigo hacer las mismas cosas con menos codigo sin renunciar a la legibilidad, o cuando con un poco mas se amplia la funcionalidad considerablemente.
El copy & paste es una barita magica para crear bugs, pero si no lo haces de vez en cuando que haces? te implementas tu mismo todas las funciones, metodos, apis, llamadas al sistema, y .. el sistema operativo? si no eres linus torval no me parece una buena idea.
[...] Signs You're a Crappy Programmer (and don't know it). Hace unos días apareció en mundogeek.net una traducción de [...]
Sobre lo de usar Java solamente, olvidas que en España, el 90% de los grandes clientes imponen sus propios frameworks (casi todos en Java y alguno en .NET) y no te dejan usar mejores soluciones, con lo cual supongo que no has currado mucho en este mundillo aún… Sigue soñando que es bonito.
Yo añadiría a aquellos que sólo hacen consultas a una base de datos mediante procedimientos almacenados (la vieja escuela). Bienaventurados ellos que sus programas serán infinitamente más seguros y rápidos, y sin hablar de la facilidad de mantenimiento.
[...] está mal el texto para seguirlo como "12 cosas que no debes hacer cuando programa", aunque con este título de la entrada, se puede decir aquello de: "la primera en la [...]
VIVA EL COPY PASTE!!!!
La verdad es que hoy me siento decaido, y queria comentar mi propia experiencia. Hace años hubiera dicho que sí indiscutiblemente al punto 1. Java es todo lo que necesitas.
Estuve programando en Java alla por el año 1998 con el JBuilder 3.0, colaborando con el Framework y a la vez "habia que comer" una aplicación de facturación para los clientes. Bien, después de 2 años y 4 personas colaborando, fuimos capaces de hacer un programa que iba lentísimo.
Pero eso sí UML, programación 3 capas, la verdad es que aprendí mucho, pero a nivel de empresario fue una ruina o quizas no fue el momento, por la lentitud de la herramienta.
Actualmente, hacía como 5 años que no tocaba Java la cosa ha evolucionado y bueno todo va rapidisimo, el Eclipse ni punto de comparación con el primero que vi.
Sobre el: 3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
Bueno hay que ser un poco flexibles pero ciertamente hay "partir" o pensar si se puede partir cuando tienes 20 lineas.
Sobre el punto 8. Te enorgulleces enormemente del gran volumen de código que escribes.
y el
9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Estoy totalmente en desacuerdo, me lo encuentro todos los dias cuando me tocar hacer alguna modificación, a mi modo de entender es dejadez del programador que lo ha creado.
Disculpad por el desorden de este comentario.
Saludos.
Vaya ¿es que no se puede hacer todo con Java?
Pos con lo que me ha costado Java , como tenga que aprender otra cosa……
¡Excelente post! hay como 2 o 3 en las que fallo, ahora me voy a poner a reflexionar sobre ello y evitar hacerlo.
[...] 28 Noviembre 2007 por Ricardo Pluss Fuente: mundogeek [...]
Soy un mal programador =) jaja El 95% de las cosas que escribo, las escribo en java.
todo el mundo odia a java ~ todo el mundo usa (y usara) java..
Yo agregaría esta:
13. Le llamas "librerías" a las bibliotecas.
Saludos.
Al González.
Fundador de Programadores Delphi de México.
David Wrote:
>perl, …., los lenguajes de scripts estan para lo que estan,
Un script es lo que se da a los actores un programa es lo que se da al publico.
> no hay sistemas operativos escritos en java ni en python.
Pero si en en Perl
http://perllinux.sourceforge.net/
Hola a todos,
hay cosas ciertas y otras que quiero comentar. Desde el punto de vista del codigo chapuza y diseños poco escalables, escribir código sin diseño es algo prehistorico y que en estos momentos no es viable. Los diseños en UML ayudan y es una forma tan válida como otra cualquiera de enteder a priori el código que luego vas a generar. Saber exáctamente los procedimeintos a utilizar no siempre es posible, aunque si los más importantes están reflejados en el diseño simplifica y acorta el tiempo de desarrollo. Como siempre un diseñador dee haber rpogramado tiempo para saber lo que se puede o no hacer en cada caso. De todas formas cosas dichas aquí son extensibles a .Net, etcetc.
Un saludo
Yo discrepo de la mayoría de puntos, aunque en algunos estoy de acuerdo, como el 6º, el del "return", XD.
Esta lista está enfocada en programación orientada a objetos y más concretamente a Java, y que yo sepa ni Java es el único lenguaje de programación, ni la orientación a objetos el único paradigma de programación.
Particularmente, yo trabajo con otros lenguajes tipo C y en sistemas críticos de tiempo real, y no uso patrones más que nada porque no existen como tales, por ejemplo, o lo que indica el punto número 5 lo rebato totalmente: los ciclos de CPU son críticos. Hoy en día estamos acostumbrados a tener el cojoordenador con el cojosistema operativo que nos resuelve esas "pequeñas incomodidades" como es el rendimiento o la respuesta de tu software.
Aun así, me gusta la idea de hacer una lista de puntos que medio-indiquen si un programador es bueno, regular, malo, o ha hecho el curso de IBM de programación por fascículos, XDD
Saludos a todos.
Hombre, Miguel Angel! creo que soy uno de esos 4 frikis de los que hablas XD. La verdad es que nos fuimos bastante de la olla, supongo que por la falta de experiencia. Lo peor es que en estos últimos años me he vuelto a encontrar en situaciones similares: chavales de 28 o 29 años que se creen gurús porque han comprado y hojeado (no leído) un par de libros de UML y patrones, y que acaban haciendo auténticos destrozos. Ese era yo hace diez años.
En cuanto a las 12 señales estoy de acuerdo con casi todas, excepto la 3 (la de las líneas por funcion) y la 4 (la de los patrones).
@Jose Luis De hecho si existen sistemas operativos escritos en Java:
JavaOS
[...] leí el post '12 señales de que eres un mal programador' y me quede alucinado por la primera señal ya soy un mal programador ¿Y tú? Estas 12 señales no [...]
Estoy de acuerdo en muchos de los puntos, pero no con el 6 (varios return),como ya ha comentado alguien. Me da que pensar que quiza no has pasado por la desagradable experiencia de mantener codigo ajeno. Efectivamente, puede ser mas facil de entender, y desde luego de programar, pero a la hora de mantener una funcion grande (mas de 20 o 30 lineas
), que tiene varios returns puede ser una pesadilla si , por ejemplo, quieres hacer algo siempre que se salga de la funcion.
Esto debe estar escrito por alguien que sabe programar pero no sabe informática. Me explico.
Incluir en esta lista de errores el modelado y el uso de patrones responde a que esta lista la ha creado alguien que o los desconoce o no sabe usarlos.
Programar sin tener un diseño previo en Ingenieria de software se llama caos.
Los patrones simplifican las cosas y facilitan la reutilización de código. Otra cosa es no saber usarlos.
Serán cosas mías pero en sitios dónde se crean aplicaciones (America, India, Japón) se utilizan técnicas de modelado y patrones.
Ignorar la importancia de los ciclos de CPU es porque se ignoran las bases de la informática. Si no, para qué incorporar en las CPUs un branch predictor si los ciclos vacios no importan? Esto está relacionado con conceptos como rendimiento, eficiencia…
Esto producirá programas más baratos y que funciones de ahí a que valgan algo "informáticamente" hablando es otra cosa.
Creo, que el autor del post los puntos que plantea son cuando se llevan a un extremo. No creo que hayan reglas fijas al momento de programar, en ese sentido: "programar es más un arte que se apoya en la técnica". Quizas por eso va ser muy dificil encontrar para un mismo problema dos programas exactamente iguales.
Finalmente, toda esta discusión la encuentro super valiosa.
La verdad es que de las 12 estoy de acuerdo con 5 o 6.
hay muchas que son una solemne tontería.
Los dos tipos de programador…
En blogs, portales de noticias, empresas, centros de educación en programación, etc. generalmente se tiende a describir distintos "tipos" de programadores. Hace en poco en un blog en TechRepublic, nombraban 10 tipos distintos de programad…
@Jose Luis
A Linux distribution where ALL programs are written in perl,
por si no has entendido lo que significa:
una distribución linux (escrita en C y asm) donde todos los programas estan escritos en perl.
Pero gracias, no la conocía.
@Zootropo
una pregunta, ¿la maquina virtual desde la que se ejecuta todo el sistema en que esta escrita?
Tampoco conocía JavaOS, me parece una gran idea, quizás algún día exista una arquitectura nativa para java, y poder hacer un sistema operativo en java, en ese momento todo el software java se ejecutara mas rápido.
"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."
Es cierto que no se puede aplicar patrones a discreción, pero de la impresión de que está en contra de ellos en absoluto. Si es así… ¿para qué coño sirven los patrones? Díselo a los ingenieros, a los Gamma y 4F, que han escrito muchos libros.
No creo que sean "de tan poca utilidad", entonces, los patrones.
Sin duda leyendo lo referente a patrones, UML y eficiencia en cuanto a "programas que tratan simplemente con una base de datos" me dan la certera idea de que quien a escrito esto ni siquiera es ingeniero. Será un efepín o ni siquiera eso. Así que de grandes proyectos ni idea.
En los demás puntos… reconozco que no le falta razón.
Yo tengo unas reglas que no dice si eres un buen programador, pero desde luego que cuando alguien las incumple esta claro que es de lo malos:
1.- Todo el codigo debe ir formateado, da igual que prefieras poner las llaves asi
Algo {
..
}
que asi
Algo
{
..
}
pero que exista un formato.
2.- Nombrar las variables para recorrer bucles con nombres cortos, a poder ser con una letra, y empezando por i,j,k,… y el resto con nombres algo mas largos.
3.- No mezclar paradigmas en un lenguaje y menos en un mismo modulo (sobre todo en C++), si estas con Objetos, no pases punteros a funciones.
4.- Hacer comentarios breves y precisos de cada función o método que no tenga un nombre que la describa bien.
5.- Seguir la convención de java de unir varias palabras poniendo la primera letra de las palabras en mayuscula salvo que sea la primera porque entonces dependera de lo que se este nombrando, o usar '_' como separador de palabras, pero usar algo!, aun sigo viendo código donde se lo pasan por el forro por raro que parezca.
6.- No poner nombre kilometricos a variables ni funciones ni métodos, abreviar cuando sean muy largos.
En realidad no son reglas, solo sentido común..
Tu eres de universidad de pago, no???
Pues nada, colegui esta claro que con gente como tu no nos hacen el colegio ni de broma.
Para Luis:
Sólo comentarte que no confundas en tu punto 3, paradigmas y formas de implementación. En C++ estas usando el paradigma de Orientacion a Objetos, o podrías usar el paradigma de programación imperativa, tanto si usas punteros en ambos casos como si no. Paradigmas pueden ser el paradigma de programación Orientado a Objetos, el Imperativo, el Funcional, el de Programación Lógica, el de Programación Orientado a Restricciones, el Relacional, etc.
En cuanto al punto 5, ¿por qué la convención de Java? ¿Sabes lo que dijo Tanenbaum hace mucho tiempo? Pseudocito porque no me acuerdo bien de las palabras concretas: "lo mejor de los estándares es que hay muchos entre los que puedes elegir".
Es decir, que las convenciones hay miles y cada uno creerá más conveniente unas u otras, y esto sí que es de sentido común.
Saludos
Me parece bien que no aceptes una crítica al diseño del blog, pero me parece mal que la censures. O obligas a registrarse para comentar o no hagas perder el tiempo a la gente y pones en un cartelito en algún lugar de la web que moderas los comentarios, sean de la índole que sean o añade una razón más para la lista de señales por las que eres un mal programador: no escuchar críticas desinteresadas sobre el producto.
Me equivoqué. Lo que puse antes era para David (dos comentarios antes del mio anterior a éste).
Sorry for the inconveniences.
Por cierto, ¿está subiendo el tono de la "discusión" o sólo me lo parece a mi? XD
Saludos
Manolo. Ese comentario se ha borrado porque no tenía absolutamente nada que ver con el tema de la entrada (como este, pero que se le va a hacer)
Para quejas, sugerencias, insultos, peticiones de adopción, proposiciones indecentes, y todo lo demás está mi correo que puedes encontrar en la sección Contacto.
¿No te ha llegado el mail?
@sebas
¿Te refieres a mí?
@pobrecito hablador
Pues a eso me referia sobre los estandares, hay muchos, y no es mala idea escoger uno, parecera una estupidez cuando se esta hablando de uml y su necesidad, pero al nivel mas bajo no es dificil ver como hay gente que no usa NINGUN estandar, ni nada con cierta logica o coherencia.
/nopedantemode on
/cast sentidodelhumor(Rank 1)
/stopcasting
/y "ACEPTAR LAS BROMAS, QUE SON PA REIRSE xD"
Hombre si JuanJo soy Miguel Angel el mismo que conociste, que pequeño es el mundo, anda enviame un mail a dominiogadget@gmail.com que no tengo tus datos.
P.D. Este chico y Antonio son una máquinas en Java, de ellos aprendí creo que todo lo que se en programación con clases.
De acuerdo en todos, sobre todo en el primero. Yo fuí programador Java mucho tiempo y conocí Ruby y bueno francamente ahora digo: "que pereza Java". Ha esta lista le falta un punto importante: "No escribes pruebas automatizadas de tu código". Eso es fundamental… y en Java… con un framework como Struts o Hibernate o Spring… es una lidia.
Yo siempre programo orientado a objetos, mas que uml hago bosquejos, de que va para aca y para alla y quienes lo usan =P
siempre uso funciones, algunas muy largas se pueden separar en varias mas pequeñas que pueden ser reutilizadas para otros fines
el acceso y manejo de datos desde Bases de datos los gestiono con un par de objetos, uno que hace la autenticacion y pelea con la BD y el otro que maneja las querys y results y me muestra las excepciones sin asesinar la ejecucion del programa, con error en mano es mas facil debuggear o indicarle al usuario que esta metiendo la pata (ya que por mucho que uno los instruya siempre encontraran la forma de hacerlo)
yo programo en PHP, por lo que para las interfaces hago plantillas y para el estilo CSS ahi no uso copy paste, simplemente invoco funciones y clases. Hacer una interface nueva me toma 3 lineas, pero en las funciones hay muchas muchas lineas que se encargan de formarla y manejar los eventos
[...] MundoGeek me encuentro con estas señales que indican cuando uno esta haciendo algo mal… algunos son [...]
[...] MundoGeek me encuentro con estas señales que indican cuando uno esta haciendo algo mal… algunos son [...]
[...] Señales De Que Eres Un Mal Programador 28 11 2007 Encontre en Mundo Geek una lista de 12 señales que podrian indicar que eres un mal programador, resultan muy [...]
todo parece indicar que el que escribio el post,.. no es muy buen programador
Esto es lo mejor que he leído en años. Lo que odio de programar es programar!
Jaja, creo que las criticas carecen de objetivos comunes. El criticar algo que no sabemos que es. Me refiero a que se esta criticando a unas reglas de programación sin conocer de que algoritmo se trata. Se quiere hacer recetas de programación!! NO. No se puede hacer recetas de programación. Depende de las condiciones del algoritmo. Depende del lenguaje.
El punto de UML es muy importante. UML es parte de documentación y no solo describe clases. Existe muchos otros diagramas en UML. UML es importante, forma parte de la documentación, ayuda a la logica del planteamiento del código y punto.
Ese otro punto de que eres un inútil si te tienen que testear no estoy de acuerdo. Es lógico que alguien tenga que hacer pruebas a tu código. Tu no eres un dios para hacer todo un sistema completamente solo. El programador no hace al sistema, lo hacen todos, inclusive hasta el usuario!
saludos
[...] MundoGeek me encuentro con estas señales que indican cuando uno esta haciendo algo mal… algunos son [...]
[...] Fuente [...]
*/———————————————-*
Al González
Yo agregaría esta:
13. Le llamas "librerías" a las bibliotecas.
Saludos.
Al González.
Fundador de Programadores Delphi de México.
*/———————————————-*
Hola a todos…
muy bueno el post.. estoy de acuerdo con algunas cosas y con otras no.. por ejemplo.. lo de los usuarios estupidos y que sin usuarios la programacion estaria mejor.. que mejor va a estar??.. sin usuarios no exitiria la programacion!! asi de sencillo.. lo que pasa es que es mas facil escribir un codigo que uno entienda a escribir un codigo que sea entendible y estable.. lo del un solo return por funcion me parece algo tonto aunque siempre depende del codigo que estes haciendo.. UML lo odio pero tengo que reconocer que siempre se debe tener un mapa mental asi sea basico de lo que uno va a hacer antes de escribir codigo.. y Al en cuanto lo de libreria y biblioteca creo que el tratar de ser tan puristas lo que hace es desviar lo esencial del tema.. no creo que porque un programador llame a una biblioteca libreria, solo por ese hecho.. sea mal programador.. estamos de acuerdo que todo viene de la traduccion "library".. pareciera que es libreria cuando realmente es biblioteca.. libreria seria algo como books shop o tiendas de libros.. pero no creo que esa sea un punto a favor de que alguien sea mal programador.. sino todos somos malos porque en algun momento deciamos "libreria" jajaja..
Saludos!
""Papel y boli son las mejores herramientas que existen para la programación""
Estoy completamente de acuerdo con esto
Por otro lado, yo opino que las funciones, métodos tienen que ser lo más simplistas y cortos posibles, y nada de ser mal programador al pensar eso
[...] Mundogeek & Damien Katz Signs You're a Crappy Programmer (and don't know [...]
[...] 12 señales de que eres un mal programador [...]
[...] Fuente: Aqui [...]
Simpático el post.
Perdón, yo programo para usuarios tontos, los inteligentes hacen sus propios programas, y precisamente poniéndome en el lugar de un usuario tonto trato de atajar la mayor cantidad de errores posibles y al mismo tiempo hacer el programa lo más fácil posible de usar, de eso se trata o no?
Yo creo que el modelado no es exclusivo de un programador y mucho menos de alguien de sistemas. El modelar es expresar una idea y seguir un flujo que te puede ayudar a encontrar consistencias e inconsistencias en una propuesta.
El modelado no debe ser una interpretación de algo que se llevará a código máquina, debe pensarse también como un análisis y propuesta que se le hace a una persona que no conoce de sistemas pero entiende de forma gráfica los pasos que se requieren para concluir una solución automatizada por código máquina.
[...] 12 señales de que eres un mal programador A mi no me convence mucho este patrón, pero para gustos colores. Liberado Resource Manager Application Block Inside c# (redondeo al "par más próximo") Deshabilitar el chequeo de compatibilidad de extensiones en las betas de firefox 3 Inside c# (valores por defecto) Patrones (Patrón provider) Métodos de extensión (String formatting with named variables) Si tienes un problema y puedes resolverlo con expresiones regulares, tienes dos problemas. ¿O no? Rendimiento (Imagenes nativas) Linq (Si estas haciendo un bucle….) [...]
Los punteros en C son cosa de diversion,
char *ptr1 = "hola puntero";
char **ptr2 = 0;
ptr2 = &ptr1;
cout << *ptr2 << endl;
printf("%s", ptr1 );
Creo que es fundamental la imaginacion primero para dominar la tecnica.
Creo que faltó lo de nombrar variables a lo tonto, jeje… por ejemplo:
int a, b, c, d, e, f;
jajaja…
Solo estoy de acuerdo con la 11…
Soy de los que opina que el mundo es mucho mas sencillo de lo que dicen los blogs.