Leyes de la programación

Este artículo necesita ser ilustrado. Busca una afoto en Guguel o donde sea, ponla y que no sea pr0n, que se cabrea el señor del adSense y nos corta el grifo de los dólare. Y sin dólare no hay servidor...

Archivo:Teclearhastalamuerte.gif

Informática Este artículo contiene humor acerca de la informática y/o internerd, por lo que si no te la pasas 29 horas diarias pegado al ordenador, presiona Alt+F4.

Como toda ciencia técnica, la programación tiene sus leyes y teoremas, pero como teoremas no me da la gana inventármelos no son imprescindibles, no los adjuntaré.

Leyes básicas de la programación

• Ley primordial: Si algo funciona, ¡no lo toques!
  • Anexo a la ley primordial: Si modificas el código y no te funciona, no tendrás una copia suficientemente actualizada como para no deprimirte.

Leyes de la presentación de proyectos

• Si se copia parte de un proyecto de otro programador o grupo de programadores, se debe intentar que ese grupo nunca pueda presentar la práctica.
  • Anexo: Pese a cambiar variables y nombres tras una copia, o el código se vuelve inoperativo (como respuesta a la ley primordial) o el examinador/profesor lo descubre.
• Las palabras ‘Es el efecto demo’ sólo funcionan cuando se presenta un proyecto ante otros programadores, no ante humanos cualesquiera.
  • Anexo: Justo al terminar la presentación, comprobarás que tu proyecto estaba perfecto y funcional 100%.
• Cualquier programa funcionará perfectamente en un entorno impuro y lleno de intrusiones como puede ser tu casa, pero dejará de funcionar en un entorno cerrado e impoluto como puede ser el ordenador de la presentación de tu proyecto.
  • Anexo: Si el ordenador en la presentación es el tuyo, no sólo no funcionará, sino que aparecerán fotografías comprometedoras que pondrán en peligro tu nombre público.
• Cualquier medio extraible en el que tengas que presentar el proyecto, vendrá con un defecto de fábrica indetectable hasta el día en el que tengas que entregarlo.
  • Anexo: El defecto será directamente proporcional a la importancia del proyecto y cuadráticamente proporcional a la antigüedad del medio en cuestión (si usas tarjetas perforadas no te molestes siquiera en intentarlo y pide que actualicen el hardware).

Leyes prácticas

• El de tu lado siempre tiene un proyecto mejor, más rápido y más fácil de interpretar mentalmente que el tuyo.
  • Anexo: Si ése no es el caso, será más lento y difícil de entender, pero a él le funcionará y a ti no.
  • Anexo: Pese a todo, el 90% de los casos, el de tu lado tendrá un proyecto mejor, más rápido, más fácil de interpretar, le funcionará y a ti no.
• Tras hacer un programa perfecto, éste no funcionará en ningún ordenador.
• Tras depurar un programa y encontrar un error irremediable, éste será fácilmente encontrado por el primero que pase por detrás de ti.
  • Anexo: Siempre, SIEMPRE será porque te has olvidado un punto y coma o porque pusiste una variable mal escrita.
  • Anexo: En ninguno de los casos, solucionar el problema (tras conocerlo) llevará más de 2 minutos.
• Cuando un lenguaje pueda tener punteros (como el C), éstos serán los responsables de la mayoría de errores en la post-compilación.
  • Anexo: Si el lenguaje no los tiene visiblemente (como Java), sólo se mostraran días pares. Los impares el programa fallará por otro lado.
    • Anexo de anexo: A más cantidad de objetos creados en Java, menos posibilidades de salir airoso tras compilar.
• Siempre quedará en comentarios una función súpernecesaria para la práctica.
  • Anexo: En caso que todas las funciones estén operativas, siempre quedará un comentario que te incrimine de copia o de insultos al profesor/encargado.

Paralelismo a las leyes de Murphy

• Si algo puede salir mal, no lo hará hasta la entrega/presentación del proyecto.
• Siempre hay una forma más sencilla de hacer algo, pero no siempre hay tiempo.
  • Anexo: Con el tiempo, esa forma más sencilla eleva exponencialmente el nivel de dificultad del trabajo final.