Cómo no realizar una práctica de programación

Cómo NO realizar una práctica de programación
Inevitablemente, los alumnos (¡y muchos profesionales!) repiten ciertos patrones de comportamiento muy nocivos al hacer prácticas de programación. Este documento pretende recoger los peores hábitos, reunirlos, y presentarlos de forma que un alumno (¡o un programador profesional!) pueda identificarlos fácilmente y evitarlos. Si su intención es poner aprueba al profesor, sin embargo, no debería evitarlos, sino seguir estas instrucciones al pie de la letra.
Quiero dejar constancia de que esta página, aunque esté escrita en tono relativamente jocoso y exagerado (con el fin de hacer más llevadera su lectura y desdramatizar), no pretende en modo alguno ser una burla hacia los alumnos, hacia los que siento un gran respeto. Gran parte de estapágina la he escrito por el simple mecanismo de ridiculizarme a mí mismo, ya que en un momento u otro he cometido muchas de estas faltas, y las entiendo muy bien. Otras me parecen increíbles, pero en fin... El caso es que sólo se pueden evitar con cierta disciplina, y darse cuenta de lo absurdos que son ciertos comportamientos puede ser una buena forma de adquirir esa disciplina (el miedo al ridículohace milagros).
• De la programación propiamente dicha
o Ignora los mensajes de error
o Ignora las advertencias, "warnings" o "hints"
o Escribe el código directamente sin pensar
o Aunque el código no compile o no funcione, sigue escribiendo
o Si el código tiene un error que no se produce siempre, ignóralo y sigue escribiendo
o Si el código tiene un error que se produce siempre, cambia cosasaleatoriamente hasta que desaparezca
o Construye enormes porciones de código sin compilar / ejecutar / probar
o No escribas comentarios, salvo los obligatorios
o Ignora los enunciados
o Ignora las normas de programación y presentación
o Escribe la documentación al final
o No aprendas a utilizar el depurador ni otras herramientas
o No utilices jamás breakpoints al depurar un programa
• De larelación con el profesor
o No pidas ayuda
o Nunca describas un problema en detalle
o Lleva siempre los fuentes equivocados
o No aísles el problema
o Usa el correo electrónico con habilidad
o Eskríbelo todo cn abrvtrs o konsonantes ekstrañas
o Comete faltas de ortografía
o No te identifiques
• Y, sobre todo...
o Deja el trabajo para el final
o Copia las prácticas
o No vayas a clase
Dela programación propiamente dicha
Ignora los mensajes de error
Los compiladores, los sistemas operativos, etc. emiten mensajes de error sólo para que los usen sus creadores, o para justificar sus sueldos.
Leer esos mensajes, además, lleva un tiempo precioso que se podría dedicar a escribir más código, por lo que atentan contra nuestra productividad.
Y por último, para entender esos mensajeshacen falta conocimientos informáticos -cosa que no debemos cultivar, ya que en realidad todos estamos estudiando para jefes-, y encima... ¡la mayoría de las veces esos mensajes están en inglés! No caigas en la trampa. Ignóralos.
Ignora las advertencias, "warnings" o "hints"
Al igual que en el caso de los errores, estos mensajes son difíciles de entender (por lo menos más difíciles que losmensajes cortos de los móviles), y encima suelen estar en inglés.
Es más, ignorar los "warnings" le da a uno una pátina de programador profesional que no tiene miedo de los ordenadores. ¿Qué mejor demostración de madurez como programador que presentar un programa que al compilar da decenas, no, cientos de warnings, sin que su autor se inmute? Se nota que es un programador experimentado, que no seamilana por nada, y que además está demasiado ocupado para perder el tiempo con tonterías.
Escribe el código directamente sin pensar
Al final, no nos engañemos. ¿Qué es lo que estamos construyendo? Un programa. ¿Qué es lo único imprescindible en un programa? El código. ¿Qué es lo que de verdad funciona? El código. No hay que perder ni un minuto en usar medios arcaicos como lápices, bolígrafos o...