SINOPSIS

Sigue esta guía y soluciona tus problemas.

Mi Filosofía del Debugging

Creo en tres cosas:

No es nada personal

Olvida que eres el dueño de tu código. Quizás te creas y te sientas como un artista, pero hasta los Grandes Maestros escriben un montón de mierda. El código de todos es una mierda, así que mi código es una mierda, y tu código es una mierda. Aprende a aceptarlo. Cuando encuentres un problema, tu primer pensamiento debería ser "hay algo malo en mi código de mierda". Así, no tienes que maldecir a Perl. No es nada personal.

También olvida la forma en cómo tú haces las cosas. Si la forma en como haces las cosas funcionara, no estarías leyendo esta guía. Pero eso tampoco es algo muy malo. Sólo que ya es tiempo de evolucionar. Todos hemos pasado por eso.

Responsabilidad propia

Si tienes un problema con tu script, es sólo eso ---tú problema. Deberías tratar de resolverlo por tí mismo tanto como puedas. Recuerda, todos los demás tienen sus propios scripts, lo que significa que todos tienen sus propios problemas. Haz bien tu trabajo y dale lo mejor de ti antes de molestar a otro con tus problemas. Si honestamente intentaste todo lo que sale en esta guía y aun no puedes resolverlo, has dado lo mejor de ti y es tiempo de molestar a algún otro.

Cambia la forma en que haces las cosas

Arregla las cosas, para que no tengas el mismo problema de nuevo. El problema probablemente es cómo escribes código, no qué cosas escribes. Cambia la forma en que haces las cosas, y te harás la vida más facil. No intentes adaptar a Perl a ti, porque no lo hará. Adáptate tu a Perl. Es sólo un lenguaje, no una forma de vida.

Mi método

¿Estás compilando tu script en forma estricta?

Si no estás usando código estricto, hazlo ahora. Los gurúes de Perl son gurúes porque usan strict siempre, lo que les da tiempo para resolver otros problemas, aprender nuevas cosas, y subir módulos que funcionan a CPAN.

Puedes encender el código esctricto con el pragma strict :

use strict;

También puedes encender el código estricto desde la línea de comandos con la opción -M :

perl -Mstrict script.pl

Puede que al principio te moleste mucho programar con código estricto, pero luego de un par de semanas de uso escribirás mejor código, perderás menos tiempo cazando errores estúpidos, y probablemente no necesites volver a esta guía.

¿Qué es esa advertencia?

Perl puede advertirte cada vez que encuentre un código cuestionable. Enciende las advertencias, y deja que Perl te ayude.

Puedes encender las advertencias en la línea she-bang:

#!/usr/bin/perl -w

O también puedes usarlas desde la línea de comandos:

perl -w script.pl

Recibirás advertencias lexicográficas muy interesantes. Revisa el pragma "warnings" para más detalles.

use warnings;

Si no entiendes lo que te dice una advertencia, puedes buscar la versión completa de ella en perldiag o puedes usar el pragma diagnostics dentro del código

use diagnostics;

¡Resuelve el primer problema primero!

Después que Perl te entregue mensajes de error o de advertencia, arregla el primer mensaje y después ve si Perl te sigue arrojando los otros. Pasa muchas veces que el resto de los mensajes son consecuencia sólo del primer problema.

¡Revisa el código anterior a la línea donde tienes el mensaje de error!

Perl te entrega mensajes de advertencia sólo donde le preocupa, y no antes. Para cuando perl está preocupado, puede que el problema ya haya ocurrido, y la línea de error que arroja Perl está después del problema. Revisa siempre un par de expresiones antes de la línea del error.

¿El valor es realmente el que crees que es?

¡No adivines! Mejor que eso es examinar el valor real antes que lo uses en una expresión. El mejor debugger en el universo es print:

print STDERR "El valor es [$valor]\n";

Siempre encierro $valor entre corchetes para que revisar si hay espacios o saltos de línea dentro del valor.

Si tengo cualquier cosa que no sea un escalar, uso Data::Dumper para imprimir la estructura.

require Data::Dumper;
print STDERR "El hash es ", Data::Dumper::Dumper( %hash ), "\n";

Si el valor no es el que crees que debería ser, ¡devuélvete algunos pasos e intenta de nuevo! Hazlo hasta el punto donde tu valor deja de ser lo que tu piensas que debería ser.

También puedes usar el debugger interno de perl con la opción -d. Revisa perldebug por más detalles.

perl -d script.pl

También puedes usar otros debuggers o ambientes de desarrollo, como ptkdb (un debugger gráfico basado en Tk) o Komodo (un IDE para Perl hecho por ActiveState, basado en Mozilla).

¿Estás usando la función en forma correcta?

Llevo programando Perl desde hace mucho tiempo, pero así y todo miro perlfunc casi todos los días. Algunas cosas nunca me salen a la primera, y otras veces estoy tan falto de sueño que pierdo mis sentidos y me encuentro preguntando por qué sprintf() no me imprime a la pantalla.

Puedes revisar una función en particular con el comando perldoc y su opción -f

perldoc -f nombre_funcion

Si estás usando un módulo, revisa su documentación para asegurarte que lo estás usando en forma correcta. Puedes revisar la documentación del módulo usando perldoc.

perldoc Nombre::Modulo

¿Estás usando la variable especial en forma correcta?

Igual que perldoc, siempre estoy mirando perlvar. Bueno, en realidad no tanto desde que encontré el "Perl Pocket Reference" mucho más simple de usar.

¿Tienes la versión correcta del módulo?

Algunos módulos cambian su comportamiento entre versiones. ¿Tienes la versión del módulo que crees tener? Puedes revisar la versión de la mayoría de los módulos con una línea:

perl -MNombre::Modulo -le 'print Nombre::Modulo->VERSION';

Si acostumbras a leer la documentación fuera de tu máquina, como en http://www.perldoc.com o http://search.cpan.org, entonces lo más probable es que estés usando una versión distinta localmente.

¿Has hecho un pequeño caso de prueba?

Si estás intentando usar algo nuevo o piensas que un trozo particular del código está actuando raro, escribe el programa más corto posible que haga justo ese trozo. Esto elimina la mayor parte de los otros factores que pueden estar influyendo. Si este pequeño programa hace lo que debería hacer, entonces el problema no está en ese código. Si el programa no hace lo que tu piensas que debería hacer, entonces acabas de descubrir el problema.

¿Revisaste el ambiente?

Algunas cosas dependen de variables de ambiente. ¿Estás seguro de estar usando la configuración correcta? ¿Es tu ambiente el mismo que verá el programa cuando se ejecute? Recuerda que los programas para usar en CGI o en trabajos cron pueden ver un ambiente muy distinto al que tú ves en tu shell interactivo, especialmente si estás en una máquina distinta.

Perl almacena el ambiente en %ENV. Si necesitas una de estas variables, asegúrate de entregar un valor por defecto si éste no existe, aún si es solo para hacer pruebas.

Si aún tienes problemas, revisa el ambiente:

require Data::Dumper;
print STDERR Data::Dumper::Dumper( \%ENV );

¿Revisaste en Google?

Si tienes un problema, probablemente alguien más ya lo tuvo antes. Mira si alguna otra persona ha posteado algo en el grupo usenet comp.lang.perl.misc, buscándolo en Google Groups (http://groups.google.com). La diferencia entre la gente que preguntas cosas en usenet y quienes las responden está en la habilidad de usar Google Groups efectivamente.

¿Les has hecho un perfil de ejecución (profiling) a tu aplicación?

Si quieres revisar por qué tienes partes tan lentas en tu programa, ¿por qué no le haces un perfil de ejecución? Deja que Devel::SmallProf haga el trabajo pesado. Este módulo cuenta cuántas veces Perl ejecuta cada línea de tu código y cuánto se demora, imprimiendo un lindo informe.

¿Cuál es la prueba que falla?

Si tienes un paquete de pruebas, ¿cuál es la que falla? Deberías encontrar el error muy rápido, ya que cada prueba revisa solo una pequeña parte del código.

Si no tienes un paquete de pruebas, ¿por qué no hacer uno ahora? Si tu script es realmente pequeño, o si es un script para usarlo sólo una vez, entonces no tiene sentido hacerle pruebas. Pero cualquier otra cosa más allá de eso se puede beneficiar enormemente con algunos scripts de prueba. Test::Harness lo hace tan simple que no tienes excusas para no hacerlo. Si no tienes tiempo, quizás estás gastando mucho en debuggear scripts que no tienen pruebas. Después de todo, MakeMaker no es tan solo para módulos.

¿Le has contado tu problema al osito?

Explica tu problema en voz alta. Estoy hablando en serio. Sólo hazlo.

Durante un par de años tuve el placer de trabajar con un programador muy bueno que podía resolver casi cualquier problema. Cuando me encontraba realmente atrapado en algo, caminaba hasta su escritorio y empezaba a contarle mi situación. Usualmente no había pasado de la tercera frase cuando le decía "`¡Espera! no te preocupes... ya lo tengo".

Es probable que necesites hacer mucho esto, así que recomiendo que consigas algún peluche de juguete para que actúe como tu terapeuta Perl, y así no molestes a tus colegas. Tengo un osito de peluche sentado en mi escritorio y le explico todos mis problemas a él. Mi novia ni siquiera pone atención cuando empiezo a hablarme a mí mismo.

¿Se ve distinto tu problema en papel?

Has estado sentado frente a una pantalla, así que quizás un medio distinto te haga ver las cosas de otra forma. Trata imprimiendo una copia en papel de tu programa.

¿Has mirado en Los Simpsons?

Hablando en serio, quizás no te gusten Los Simpsons, pero puedes probar con cualquier otro programa. Toma un descanso. Deja de pensar en tu problema y deja que tu mente se relaje. Vuelve más tarde a él y verás que la solución aparecerá mágicamente.

¿Has guardado tu ego?

Si aún hasta aquí no has solucionado tu problema, quizás se trate de algo sicológico. Puede ser que te encuentres emocionalmente amarrado a una parte de tu código, por eso no lo cambias ni lo revisas. Quizás piensas que todos están equivocados, excepto tú. Cuando piensas así, no estás considerando en serio la fuente más probable de bugs ---tú mismo. No ignores nada. Verifica absolutamente todo.

Autor

brian d foy, bdfoy@cpan.org

Traducción al español por Hugo Salgado, huguei@cpan.org, con permiso del autor.
Versión original: http://www252.pair.com/comdog/brian%27s_guide.pod

Derecho de autor

Copyright 2002, Perl Documentation Project,
Todos los derechos reservados.