test information gui debugger debug check activar debugging ide

debugging - information - ¿Por qué la depuración es mejor en un IDE?



take gui snapshot netbeans (29)

He sido desarrollador de software por más de veinte años, programando en C, Perl, SQL, Java, PHP, JavaScript y recientemente Python. Nunca tuve un problema que no pude solucionar con un poco de cuidado y declaraciones de print depuración bien colocadas.

Respeto que mucha gente diga que mis técnicas son primitivas, y que usar un depurador real en un IDE es mucho mejor. Sin embargo, según mi observación, los usuarios de IDE no parecen depurar más rápido o con más éxito que yo, usando mis cuchillos de piedra y mis pieles de oso. Estoy sinceramente abierto a aprender las herramientas adecuadas, nunca me han mostrado una ventaja convincente para usar depuradores visuales.

Además, nunca he leído un tutorial o libro que muestre cómo depurar de manera efectiva utilizando un IDE, más allá de los conceptos básicos de cómo establecer puntos de interrupción y mostrar el contenido de las variables.

¿Qué me estoy perdiendo? ¿Qué hace que las herramientas de depuración IDE sean mucho más efectivas que el uso cuidadoso de las declaraciones de print de diagnóstico?

¿Puede sugerir recursos (tutoriales, libros, screencasts) que muestran las mejores técnicas de depuración de IDE?

¡Dulces respuestas! Muchas gracias a todos por tomarse el tiempo. Muy iluminador Yo voté por muchos y no voté ninguno.

Algunos puntos notables:

  • Los depuradores pueden ayudarme a realizar inspecciones o modificaciones ad hoc de variables, códigos o cualquier otro aspecto del entorno de tiempo de ejecución, mientras que la depuración manual requiere que detenga, edite y vuelva a ejecutar la aplicación (lo que posiblemente requiera una recompilación).
  • Los depuradores pueden conectarse a un proceso en ejecución o usar un volcado de emergencia, mientras que con la depuración manual, se necesitan "pasos para reproducir" un defecto.
  • Los depuradores pueden mostrar estructuras de datos complejas, entornos de subprocesos múltiples o pilas de tiempo de ejecución completas de manera más fácil y legible.
  • Los depuradores ofrecen muchas formas de reducir el tiempo y el trabajo repetitivo para realizar casi cualquier tarea de depuración.
  • Los depuradores visuales y los depuradores de consola son útiles y tienen muchas características en común.
  • Un depurador visual integrado en un IDE también le brinda acceso conveniente a la edición inteligente y todas las demás características del IDE, en un único entorno de desarrollo integrado (de ahí el nombre).

¿Es esta incluso una pregunta real del programador real?

¡Cualquiera que haya pasado incluso 5 minutos depurando con declaraciones de impresión y depurando con IDE, se le ocurrirá sin siquiera preguntar!

Además de las muchas cosas que ya se han mencionado, una de las ventajas más importantes de un depurador sobre printf es que el uso de instrucciones printf asume que usted sabe en qué función reside el error. En muchos casos no es así, por lo que debe hacer algunas conjeturas y agregar declaraciones de impresión a muchas otras funciones para poder localizarlo. El error puede estar en el código del framework o en algún lugar muy alejado de donde crees que está. En un depurador, es mucho más fácil establecer puntos de interrupción para examinar el estado en diferentes áreas del código y en diferentes puntos en el tiempo.

Además, un depurador decente le permitirá realizar una depuración de estilo de impresión adjuntando condiciones y acciones a puntos de interrupción, de modo que aún conserve los beneficios de la depuración de printf, pero sin modificar el código.

Además de mucho de lo que han dicho los otros carteles, realmente me gusta caminar a través de una línea a la vez junto con la computadora, ya que me obliga a pensar en una línea a la vez. A menudo atraparé el error sin siquiera mirar los valores de las variables simplemente porque me veo obligado a mirarlo cuando hago clic en el botón ''siguiente línea''. Sin embargo, no creo que mi respuesta te ayude, Bill, porque probablemente ya tengas esta habilidad.

En cuanto a los recursos de aprendizaje, no los he usado, solo exploro todos los menús y opciones.

Algunos ejemplos de algunas habilidades que un depurador IDE le proporcionará para rastrear mensajes en el código:

  • Vea la pila de llamadas en cualquier punto en el tiempo, proporcionándole un contexto para su marco de pila actual.
  • Ingrese en bibliotecas que no puede volver a compilar para agregar trazas (suponiendo que tiene acceso a los símbolos de depuración)
  • Cambiar los valores de las variables mientras el programa se está ejecutando
  • Editar y continuar: la capacidad de cambiar el código mientras se está ejecutando e inmediatamente ver los resultados del cambio.
  • Poder ver variables, ver cuándo cambian
  • Ser capaz de omitir o repetir secciones de código para ver cómo funcionará el código. Esto le permite probar cambios teóricos antes de hacerlos.
  • Examine los contenidos de la memoria en tiempo real
  • Le avisa cuando se lanzan ciertas excepciones , incluso si son manejadas por la aplicación.
  • Rotura condicional ; detener la aplicación solo en circunstancias excepcionales para permitirle analizar la pila y las variables.
  • Vea el contexto de subprocesos en las aplicaciones de subprocesos múltiples, lo que puede ser difícil de lograr con el rastreo (ya que las trazas de diferentes subprocesos se intercalarán en la salida).

En resumen, las declaraciones impresas son (generalmente) estáticas y tendrá que volver a compilar para obtener información adicional si sus declaraciones originales no fueron lo suficientemente detalladas. El IDE elimina esta barrera estática, brindándote un juego de herramientas dinámico al alcance de tu mano.

Cuando empecé a codificar, no podía entender cuál era el problema con los depuradores y pensé que podía lograr cualquier cosa con el rastreo (sin dudas, eso estaba en Unix y el depurador era GDB). Pero una vez que aprenda a usar correctamente un depurador gráfico, no quiere volver a imprimir las declaraciones.

Aquí hay una cosa que definitivamente no puede depurar con la instrucción "imprimir", que es cuando un cliente le trae un volcado de memoria y le dice "su programa se colgó, ¿puede decirme por qué?"

Como alguien dijo arriba: ¡Depurador! = IDE.

gdb y (de vuelta en el día) TurboDebugger (autónomo) funcionan bien para los idiomas que admiten [ed], gracias. (o una tecnología aún más antigua: depurador Clipper vinculado en el ejecutable xBase) - ninguno de estos requiere un IDE

Además, aunque la codificación C / ++ es más rara, las declaraciones printf a veces enmascaran el mismo error que estás tratando de encontrar. (problemas de inicialización en auto vars en la pila, por ejemplo, o asignación / alineación de memoria)

Finalmente, como otros dijeron, puedes usar ambos. Algunos problemas en tiempo real casi requieren una impresión, o al menos un juicioso "* video_dbg = (is_good? ''+'': ''-'');" en algún lugar de la memoria de video. Mi edad se muestra, esto fue en DOS :-)

TMTOWTDI

Como alternativa a la depuración en IDE puedes probar la extensión de Google Chrome con la consola de PHP con la biblioteca php que permite:

  • Consulte errores y excepciones en la consola JavaScript de Chrome y en ventanas emergentes de notificaciones.
  • Vuelca cualquier variable de tipo.
  • Ejecute el código PHP de forma remota.
  • Proteger el acceso por contraseña
  • Registros de la consola grupal por solicitud.
  • Salte al archivo de error: línea en su editor de texto.
  • Copie datos de error / depuración al portapapeles (para probadores).

Con un depurador IDE, puede ver los valores de TODAS las variables en el ámbito actual (en la parte superior de la pila de llamadas) cada vez que detiene la ejecución.

Las instrucciones de impresión pueden ser geniales, pero arrojar tanta información a la pantalla en cualquier lugar dado puede producir una gran cantidad de declaraciones impresas.

Además, muchos depuradores IDE le permiten escribir y evaluar métodos, y evaluar miembros mientras está detenido, lo que aumenta aún más la cantidad de instrucciones de impresión que tendría que hacer.

Sin embargo, creo que los depuradores son mejores para algunos idiomas que para otros ...

Mi opinión general es que los depuradores IDE son absolutamente asombrosamente maravillosos para lenguajes administrados como Java o C #, son bastante útiles para C ++ y no son muy útiles para lenguajes de scripting como Python (pero podría ser que simplemente no he probado un buen depurador para cualquier lenguaje de scripts aún).

Me encanta el depurador en IntelliJ IDEA cuando desarrollo Java. Solo uso declaraciones de impresión cuando uso Python.

Creo que la depuración usando declaraciones impresas es un arte perdido, y muy importante para que cada desarrollador aprenda. Una vez que sepa cómo hacerlo, será más fácil depurar ciertas clases de errores de esa manera que a través de un IDE. Los programadores que conocen esta técnica también tienen una muy buena idea de qué información útil incluir en un mensaje de registro (sin mencionar que en realidad terminará leyendo el registro) para fines no relacionados con la depuración.

Dicho esto, realmente debería saber cómo usar el depurador paso a paso, ya que para una clase diferente de errores es MUCHO más fácil. Lo dejo con las otras excelentes respuestas ya publicadas para explicar por qué :)

Debido a que la depuración de aplicaciones de subprocesos múltiples con instrucciones de impresión te llevará a las bananas. Sí, aún puede hacerlo con instrucciones de impresión, pero necesitaría muchas de ellas y desentrañar la impresión secuencial de las declaraciones para emular la ejecución de subprocesos múltiples llevaría mucho tiempo.

Los cerebros humanos tienen una sola hebra desafortunadamente.

En mi experiencia, las impresiones simples tienen una gran ventaja que nadie parece mencionar.

El problema con un depurador IDE es que todo sucede en tiempo real. Detiene el programa en un momento determinado, luego sigue los pasos uno a la vez y es imposible retroceder si de repente quiere ver lo que sucedió antes. Esto está totalmente en desacuerdo con la forma en que funciona nuestro cerebro. El cerebro recopila información y gradualmente forma una opinión. Puede ser necesario iterar los eventos varias veces al hacerlo, pero una vez que haya pasado cierto punto, no podrá regresar.

En contraste con esto, una serie seleccionada de impresiones / registro le da una "proyección espacial de los eventos temporales". Te da una historia completa de lo que sucedió, y puedes avanzar y retroceder cuatro veces muy fácilmente simplemente desplazándote hacia arriba y hacia abajo. Hace que sea fácil responder preguntas como "A ocurrió antes de que B sucediera". Puede hacerte ver patrones que ni siquiera estabas buscando.

Entonces en mi experiencia. IDE y los depuradores son herramientas fantásticas para resolver problemas simples cuando algo en una sola pila de llamadas salió mal, y explorar el estado actual de la máquina en un determinado bloqueo.

Sin embargo, cuando abordamos problemas más difíciles donde está involucrado un cambio gradual de estado. Donde, por ejemplo, un algoritmo corrompió una estructura de datos, eso a su vez provocó que fallara otro algoritmo. O si queremos responder preguntas como "¿con qué frecuencia sucede esto?", "Suceden las cosas en el orden y de la manera que imagino que sucederán". etc. Luego, la técnica de registro / impresión "vieja fechada" tiene una clara ventaja.

Lo mejor es utilizar cualquiera de las dos técnicas cuando sea más adecuado, por ejemplo, usar el registro / impresiones para llegar a algunos errores, y pausar en un punto de corte donde necesitamos explorar el estado actual más en detalle.

También hay enfoques híbridos. Por ejemplo, cuando haces console.log (object) obtienes un widget de estructura de datos en el log que puedes expandir y explorar más en detalle. Esto es muchas veces una clara ventaja sobre un registro de texto "muerto".

Esto es lo que más uso en las ventanas de depuración VS.NET:

  • Pila de llamadas, que también es una excelente forma de descubrir el código de otra persona
  • Lugareños y relojes
  • Ventana inmediata, que es básicamente una consola C # y también me permite cambiar los contenidos variables, inicializar cosas, etc.
  • La capacidad de omitir una línea, establece que la siguiente declaración se ejecute en otro lugar.
  • La capacidad de pasar el mouse sobre las variables y tener una información sobre herramientas que me muestre sus valores.

En resumen, me da una vista de 360 ​​grados del estado de mi código de ejecución, no solo una pequeña ventana.

Nunca encontré un libro que enseñara este tipo de cosas, pero, de nuevo, parece ser bastante simple, es casi WYSIWYG.

He usado tanto impresiones como IDE para la depuración y prefiero depurar usando un IDE. El único momento para mí cuando eso no funciona es en situaciones críticas de tiempo (como la depuración de juegos en línea) en las que tiras el código con las declaraciones de impresión y luego miras los archivos de registro después de que hayan salido horriblemente mal. Entonces, si todavía no puede resolverlo, agregue más impresiones y repita.

La depuración en un IDE es invaluable en un entorno en el que los registros de errores y el acceso al shell no están disponibles, como un host compartido. En ese caso, un IDE con un depurador remoto es la única herramienta que le permite hacer cosas simples como ver stderr o stdout .

La parte superior de mi cabeza:

  1. Depuración de objetos complejos : los depuradores te permiten adentrarte en las entrañas de un objeto. Si su objeto tiene, digamos, una matriz de objetos complejos, las instrucciones de impresión solo lo llevarán hasta el momento.
  2. La capacidad de pasar el código : los depuradores también le permitirán omitir el código pasado que no desea ejecutar. Es cierto que también puedes hacer esto manualmente, pero es mucho más el código que tienes que inyectar.

No he estado desarrollando durante casi 20 años, pero me parece que con un IDE / depurador puedo:

  • ver todo tipo de cosas que podría no haber incluido en una declaración impresa
  • paso a través del código para ver si coincide con el camino que pensé que tomaría
  • establecer variables a ciertos valores para hacer que el código tome ciertas ramas

Otra cosa es que si te unes a un nuevo proyecto anterior y nadie sabe realmente cómo está haciendo el código, entonces no puedes depurar repitiendo variables / objetos / ... b / c no tienes idea de qué código es ejecutado en absoluto.

En mi trabajo me enfrento exactamente a ese tipo de situación y el XDebuging visual me ayuda a tener una idea de lo que está pasando y de dónde, en absoluto.

Atentamente

Raffael

Personalmente, creo que la respuesta es tan simple como "Un depurador integrado / IDE te proporciona una gran cantidad de información diferente rápidamente sin la necesidad de perforar los comandos. La información tiende a estar allí frente a ti sin que tengas que decirle qué hacer. mostrarte.

La facilidad con la que se puede recuperar la información es lo que los hace mejores que solo la depuración de la línea de comandos o la depuración de "printf".

Solo quería mencionar una característica útil de un depurador de consola frente a printf y vs depurador en un IDE.

Puede adjuntar a una aplicación remota (obvio, compilada en modo DEBUG) e inspeccionar su estado descargando la salida del depurador a un archivo usando tee utilidad POSIX. En comparación con printf, puede elegir dónde emitir el estado en tiempo de ejecución.

Me ayudó mucho cuando estaba depurando aplicaciones Adobe Flash implementadas en un entorno agresivo . Solo necesita definir algunas acciones que imprimen el estado requerido en cada punto de interrupción, inicie el depurador de la consola con fdb | tee output.log fdb | tee output.log , y recorra algunos puntos de interrupción. Después de eso, puede imprimir el registro y analizar la información comparando minuciosamente el estado en diferentes puntos de interrupción.

Desafortunadamente, esta característica [iniciar sesión en un archivo] rara vez está disponible en los depuradores de GUI, lo que hace que los desarrolladores comparen el estado de los objetos en su cabeza.

Por cierto, mi opinión es que uno debe planificar dónde y qué depurar antes de mirar un depurador.

Un problema con el uso de declaraciones de impresión es que hace un lío de su código. IE, tienes una función con 10 partes y sabes que se bloquea en algún lugar, pero no estás seguro de dónde. Entonces, agrega 10 declaraciones de impresión extra para identificar dónde está el error. Una vez que haya encontrado y solucionado su error, ahora debe limpiar eliminando todas esas instrucciones de impresión. Quizás harás eso. Tal vez lo olvide y terminará en producción y la consola de su usuario estará llena de impresiones de depuración.

Una cosa que me sorprende que no haya visto en otra respuesta es que los 2 métodos de depuración no son mutuamente excluyentes .

printf depuración de printf puede funcionar muy bien incluso si está utilizando un depurador estándar (ya sea basado en IDE o no). En particular, con un marco de registro para que pueda dejar todo o la mayor parte del producto liberado para ayudar a diagnosticar problemas del cliente.

Como se observa en casi todas las demás respuestas aquí, la clave de un depurador estándar es que le permite examinar más fácilmente (y potencialmente cambiar) los detalles del estado del programa. No es necesario que sepa de antemano lo que le gustaría ver: todo está disponible al alcance de la mano (más o menos).

Una razón para usar el IDE podría ser que los IDE modernos admiten más que simples puntos de interrupción. Por ejemplo, Visual Studio ofrece las siguientes funciones avanzadas de depuración:

  • definir puntos de corte condicionales (romper solo si se cumple una condición, o solo en la enésima vez que se ejecuta la instrucción en el punto de interrupción)
  • romper una excepción no controlada o cada vez que una ecxeption (específica) se va a lanzar
  • cambiar la variable mientras se depura
  • repetir un fragmento de código configurando la siguiente línea para ser ejecutado
  • etc.

Además, al usar el depurador, no tendrá que eliminar todas sus instrucciones de impresión una vez que haya terminado la depuración.

Ventajas de un depurador sobre un printf ( note no un depurador IDE sino un depurador )

  1. Puede establecer puntos de observación. Esta es una de mis formas favoritas de encontrar corrupciones en la memoria

  2. Puede depurar un binario que no puede recompilar en este momento

  3. Puede depurar un binario que tarda mucho tiempo en recompilar

  4. Puede cambiar variables sobre la marcha

  5. Puede llamar funciones sobre la marcha

  6. No tiene el problema donde no se eliminan los errores de los stateMenets de depuración y, por lo tanto, el problema de sincronización no se puede depurar de forma precisa

  7. Los depuradores ayudan con los volcados de memoria, las declaraciones de impresión no ''

Wauw, me gusta esta pregunta. Nunca me atreví a posar ...

Parece que las personas solo tienen diferentes formas de trabajar. Para mí, lo que funciona mejor es:

  • Tener un modelo mental sólido de mi código, incluida la gestión de memoria
  • Usando instrumentación (como declaraciones de impresión) para seguir lo que está sucediendo.

Me he ganado mi programación de la vida durante más de 40 años, trabajando en aplicaciones técnicas y científicas no triviales en C ++ y Python a diario, y tengo la experiencia personal de que un depurador no me ayuda un poco.

No digo que eso sea bueno. No digo que eso sea malo. Solo quiero compartirlo.

It''s not just debugging. An IDE helps you build better software faster in a lot of ways:

  • refactoring tools
  • intellisense to make api''s more discoverable, or remind of exact spelling/case of familiar items(not much use if you''ve used the same system for 15 years, but that''s rare)
  • save on typing by autocompleting variable and class names
  • find certain kinds of errors before you even start to compile
  • Automatically jump to variable/method/class declarations/definitions, even if they''re not in the same file or folder.
  • Break on unhandled and handled exceptions

Podría seguir.

  • Imprimir instrucciones a través de su código reduce la legibilidad.
  • Agregarlos y eliminarlos solo para depuración es una pérdida de tiempo
  • Los depuradores rastrean la pila de llamadas para que sea más fácil ver dónde estás
  • Las variables se pueden modificar sobre la marcha
  • Los comandos Adhoc se pueden ejecutar durante una pausa en ejecución para ayudar a diagnosticar
  • Se puede usar EN CONJUNCIÓN con declaraciones de impresión: Debug.Write ("...")

  • Un depurador IDE le permite cambiar los valores de las variables en tiempo de ejecución.

  • Un depurador IDE le permite ver el valor de las variables que no sabía que quería ver cuando comenzó la ejecución.

  • Un depurador IDE le permite ver la pila de llamadas y examinar el estado de la función que pasó valores extraños. (creo que esta función se llama desde cientos de lugares, no sabes de dónde vienen estos valores extraños)

  • Un depurador IDE le permite interrumpir condicionalmente la ejecución en cualquier punto del código, en función de una condición, no de un número de línea.

  • Un depurador de IDE le permitirá examinar el estado del programa en el caso de una excepción no controlada en lugar de simplemente generar una interrupción.

  • Un depurador se puede conectar a un proceso en ejecución

  • A menudo es más fácil depurar código enhebrado de un depurador