Trucos sobre Depuración

Artículo original: Debugging Tips
http://doughennig.blogspot.com/2006/05/debugging-tips.html
Autor: Doug Hennig
Traducido por: Ana María Bisbé York

---

Como dije en mi post http://doughennig.blogspot.com/2006/04/back-from-glgdw.html sobre GLGDW http://www.hentzenwerke.com/conferences/glgdw2006.htm, me perdí la sesión sobre las Mejores prácticas de Depuración. He aquí un par de trucos que iba a mencionar. Siento si alguien los mencionó, yo estaba tan ocupado configurando el PC de Rick para hacer mi presentación, que no escuché lo que dijeron.

1.- Escriba código que sea cómodo de depurar

Yo escribía código de este tipo:

llReturn = UnaFuncion() and OtraFuncion() and OtraFuncionMas()

Ahora no hago esto, por dos razones: es más difícil de entender que:

llReturn = UnaFuncion()
llReturn = llReturn and OtraFuncion()
llReturn = llReturn and OtraFuncionMas()

Pero, lo más importante, es más difícil de depurar. Si se ejecuta paso a paso, la ejecución va a UnaFuncion. Si decide que no necesita hacer el seguimiento dentro de esa función, y quiere saltar a la siguiente, puede pensar en Paso a paso por procedimientos para lograrlo. Desafortunadamente esto provoca que se ejecute la línea siguiente al llReturn, por tanto la única forma en que podría hacer seguimiento a OtraFuncionMas sería recorriendo UnaFuncion y OtraFuncion o agregando específicamente un SET STEP ON (o estableciendo un punto de ruptura) para OtraFuncionMas.

Vea que yo no suelo escribir este tipo de código:

llReturn = UnaFuncion()
if llReturn
  llReturn = OtraFuncion()
  if llReturn
    llReturn = OtraFuncionMas()
  endif
endif

Para mi, esto es aun más difícil de leer que el primer ejemplo.

He aquí otro ejemplo de código que yo escribía y que no se depura cómodamente:

SomeVariable = left(UnaFuncion(), 5) + substr(OtraFuncion(), 2, 1)

La razón de que no sea cómodo es que no se puede ver lo que devuelven UnaFuncion y OtraFuncion a no ser que haga seguimiento específico de su código. En su lugar, utilizo este código:

Variable1 = UnaFuncion()
Variable2 = OtraFuncion()
OtraVariable = left(Variable1, 5) + substr(Variable2, 2, 1)

De esta forma, puedo recorrer el código y ver qué devuelven estas funciones sin tener que recorrerlas. Si algo parece estar mal, podré colocarme de nuevo en la llamada y Configurar siguiente instrucción recorriendo paso a paso la función para ver qué es lo que está mal.

2.- Instrumente su aplicación

Rod Paddock, Lisa Slater Nicholls, yo y otros, hemos escrito artículos sobre instrumentar las aplicaciones. La idea es esparcir llamadas a un objeto que realice un log a lo largo de nuestra aplicación. Si el log está desactivado, no ocurre nada, si está activado, por ejemplo,  oLogger.lPerformLogging es .T.), se escribe un mensaje en una ubicación (un archivo de texto, una tabla, un log de Eventos de Windows, etc.) indicando lo que hace la aplicación. Encuentro que esto tiene un gran valor a la hora de dar seguimiento a los problemas. Aunque la generación de logs es genial, sólo brindará un vistazo de la situación en la que ocurrió el error. A veces es necesario saber cómo se llegó hasta allí.

Además, a veces el problema que experimenta el  usuario no ha generado un error, sino un problema de comportamiento. Al examinar el log de diagnóstico, podemos ver todos los pasos (en cualquier caso, son los que usted ha instrumentado) que han causado ese comportamiento. Además, puede utilizar SET COVERAGE en su aplicación; pero esto genera toneladas de información, mucho más de lo que necesita y no le dará la clave de la causa del problema. El artículo de Lisa es lo más reciente que he leído, así que es un buen punto de partida. El artículo de Rod está publicado en la revista FoxTalk en Septiembre de 1997 y el mío en octubre de 2003 de la revista FoxTalk (ambos artículos requieren estar suscrito a la revista).