How To Write Unmaintainable Code. Ensure a job for life

Grissom.

Grissom.

Lanero Reconocido
15 Dic 2003
3,948
http://thc.segfault.net/root/phun/unmaintain.html

Cabe aclarar que muchas personas ya poseen por naturaleza estas prácticas de programación, por lo cual tienen asegurado el mantenimiento de dicho código porque más nadie le meterá la mano. Je je ...

Sería bueno si alguno conoce un caso, o varios casos, de la vida real. Para comenzar, por ejemplo, yo he visto éste:
Giant Listeners

Never create separate Listeners for each Component. Always have one listener for every button in your project and simply use massive if...else statements to test for which button was pressed.

Cuando lo leí en la página me pude reir de lo bueno ! ...
 
LOL, está buenísimo!! Con esta casi me caigo de la silla:

Casting
Pass all data as a void * and then typecast to the appropriate structure. Using byte offsets into the data instead of structure casting is fun too.

Dios permita que no me encuentre nunca con algo así .... :D
 
  • Me gusta
Reacciones: 4 personas
Que tal esta:

Reverse the usual definitions of true and false. Sounds very obvious but it works great. You can hide:

#define TRUE 0
#define FALSE 1

somewhere deep in the code so that it is dredged up from the bowels of the program from some file that noone ever looks at anymore. Then force the program to do comparisons like:

if ( var == TRUE )

if ( var != FALSE )

someone is bound to "correct" the apparent redundancy, and use var elsewhere in the usual way:

if ( var )


y algo de LISP :reir: :

Lisp
LISP is a dream language for the writer of unmaintainable code. Consider these baffling fragments:

(lambda (*<8-]= *<8-[= ) (or *<8-]= *<8-[= ))

(defun :-] (<) (= < 2))

(defun !(!)(if(and(funcall(lambda(!)(if(and '(< 0)(< ! 2))1 nil))(1+ !))
(not(null '(lambda(!)(if(< 1 !)t nil)))))1(* !(!(1- !)))))



Ta buena como la de como no hacer una practica de programacion :reir:

http://www.di.uniovi.es/~cernuda/noprog.html
 
Muy bueno el articulo, voy a ver si coloco algo en practica para que las empresas siempre queden amarradas y con eso tengo asegurada la papa de por vida ;b

Claro que lo lamentable de la realidad es que si hay gente que programa asi...
 
Yo conozco uno que es asi y trabaja conmigo, es el programador estrella. Cuando me quejé con mi jefe de que el 90% de las variables de los programas eran globales y no se sabia donde carajo habian cambiado de valor, me mandó a pelar cebollas ( dar soporte tecnico ) y no más programación para mí.
El tipo tiene asegurado el puesto de por vida y aun así, a veces no entiende lo que hizó meses atras.
 
Grave la vaina, yo como practica personal utilizo nombres de variables bastante ridiculas como $yoyo, $pimienta, $lloron, $etc.. aunque compenso con la tabulación del margen que le hago a todo mi software... algunas veces documento ortras no.
 
Pero es que eso es lo tenaz! La gracia es poder codificar de manera que cuando llegue cualquier otra persona entienda sin necesidad de esfuerzo extra.
 
Muy bueno, aunque el artículo es tratado como un manual, creo yo que algunos estudiantes de sistemas ya nacen con este conocimiento en su bios setup, porque me caen con que les revise el programa que no les esta sacando los resultados esperados y no los entiende niel p.ts

Suerte.
 
juemadre, me uno al grupo de los desordenados!!!

Las unicas medio practicas de programacion que poseo es utilizar el camel type al tope(java) y dar nombres adecuados a variables y metodos.

Mi ex-compañero de trabajo, ke si era organizado, sudaba la gota gorda cuando un codigo pasaba por mis manos :p :( :muerto:

KERBEROS dijo:
Estoy revisando un programa en este momento. Una de las variables se llama "variable". Muy bien!! :)
Haz clic para expandir...

Increible!!! aunque en algun momento pense en hacerlo tambien jijiiij!

bye!
 
yo era tremendo desorden cuando comenze a programar, mis programas corrian, pero no los entendian, o lo de las variables globales.

igual ya me acostumbre a tratar de corregirle a otros estudiantes el codigo, eso de que le den clases a uno de busque donde esta el error, sirve pa algo, o tambien el de... describa que hace el programa..

igual, a muchas empresas se les vende un programa y nunca se les entrega el codigo, ellos estan atados a la persona, y el programador se hace indispensable, al solo el saber como trabaja..

es como el que trabaje con Oracle, esta asegurando su papita, porque no muchos lo trabajan.
 
El hecho es que las buenas practicas de codificación no deben ser unicamente para que "otro" comprenda nuestro código. Además sirven para que nosotros lo entendamos más facilmente lo que nos permite reducir el número de errores y poder realizar ajustes más facilmente.

No se ustedes, pero como programador de profesional y de hobbie, me encanta ver mi código bien bonito... no se.. se asemeja a lo que hacen los artistas... ellos dibujas, moldean, etc... pero nosotros escribimos... y tambien nos queda bonito! :)
 
Todos cuando estabamos aprendiendo pasamos por ahí, pero algunos se quedan y no quieren salir.

Me acuerdo en los primeros programas que hacia an C++ todas las variables eran globales y estaban declaradas al inicio de programa no usaba funciones si no puro copy & paste. Pase a usar funciones y la cosa seguia viendose mal pero ya no tanto, y unos años atras algunos profesores me mostrarón la maravilla de la programación orientada a objetos y ahí fue donde fui pasando de hacer programas pequeños, a diseñar sistemas de objetos que se relacionan entre sí y que su funcionamiento puede ser compredido por cualquier persona.

Yo no veo la buena programación como arte si no como una gran obra de arquitectura, pues en los edificios lo unico que uno vé son las paredes, las puertas, ascensores, ventanas y escaleras. Lo mismo con una API bien diseñanada, uno solo ve lo necesario y con eso trabaja, el resto de código queda cubierto por varias capas de abstracción.
 
El artículo es una burla exajerando las cosas, llevandolas al extremo, pero digamos que en el mundo real la gente que hace código confuso son programadores inexpertos, que por lo general nunca han trabajado en equipos de desarrollo y sólo han hecho proyectos individuales; también hay un perfil bien chistoso, son aquellos que pasan por una etapa especial del aprendizaje donde están aprendiendo nuevas APIs, tecnologías y por su indexperiencia no saben donde encajarlas, y emplearlas apropiadamente, terminan inmiscuyendo código que no encaja haciendo unas vainas super confusas. Por ejemplo, en C/C++, generalmente vi inadecuados usos de: continue, define, apuntadores a funciones, pragmas .... y apuesto que todos sufrieron con el famoso "gotoxy", esta instrucción si que enrreda el código ! ... el problema no era usarla, era que la mezclaban con las instrucciones importantes, los cálculos y consultas a la base de datos haciendo esa vaina dura de mantener.
 
Siempre se ofusca el código fuente, luego se genera a partir del código fuente ofuscado, pero insisto, para qué necesitas ofuscar el código fuente en C++, no es que no crea que tengas buenas razones pero me gustaría conocerlas para tenerlo en cuenta.
 

Los últimos mensajes

Los últimos temas

Arriba Pie
Atrás