¿Por qué la depuración es mejor en un IDE? [cerrado]

He sido desarrollador de software durante más de veinte años, programando en C, Perl, SQL, Java, PHP, JavaScript y recientemente Python. Nunca he tenido un problema que no podía depurar usando un pensamiento cuidadoso y printdeclaraciones de depuración bien ubicadas .

Respeto que muchas personas dicen que mis técnicas son primitivas, y usar un depurador real en un IDE es mucho mejor. Sin embargo, desde 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 pieles de oso. Estoy sinceramente abierto a aprender las herramientas adecuadas, nunca se me ha mostrado una ventaja convincente al usar depuradores visuales.

Además, nunca he leído un tutorial o libro que muestre cómo depurar eficazmente 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 reflexivo de las printdeclaraciones de diagnóstico ?

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

¡Dulces respuestas! Muchas gracias a todos por tomarse el tiempo. Muy esclarecedor He votado a muchos y no he votado a ninguno.

Algunos puntos notables:

• Los depuradores pueden ayudarme a realizar una inspección o modificación ad hoc de variables, código 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 (posiblemente requiera una nueva compilación).
• Los depuradores pueden conectarse a un proceso en ejecución o usar un volcado por caída, mientras que con la depuración manual, son necesarios "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 fácilmente y de una manera más 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 un acceso conveniente a la edición inteligente y a todas las demás funciones del IDE, en un solo entorno de desarrollo integrado (de ahí el nombre).

Algunos ejemplos de algunas habilidades que un depurador IDE le dará sobre mensajes de rastreo en código:

• Vea la pila de llamadas en cualquier momento, brindándole un contexto para su marco de pila actual.
• Ingrese a las bibliotecas que no puede volver a compilar con el fin de agregar rastreos (suponiendo que tenga acceso a los símbolos de depuración)
• Cambiar valores de 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
• Poder omitir o repetir secciones de código para ver cómo funcionará el código. Esto le permite probar los cambios teóricos antes de realizarlos.
• Examina los contenidos de la memoria en tiempo real
• Avisarle cuando se lanzan ciertas excepciones , incluso si son manejadas por la aplicación.
• Rompecabezas condicional ; detener la aplicación solo en circunstancias excepcionales para permitirle analizar la pila y las variables.
• Vea el contexto de subproceso en aplicaciones de subprocesos múltiples, lo que puede ser difícil de lograr con el seguimiento (ya que los seguimientos de diferentes subprocesos se intercalarán en la salida).

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

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

• 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 pasada valores extraños. (piense que esta función se llama desde cientos de lugares, no sabe de dónde provienen estos valores extraños)

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

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

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

• Imprimir declaraciones a través de su código reduce la legibilidad.
• Agregarlos y eliminarlos solo con fines de depuración lleva mucho tiempo
• Los depuradores rastrean la pila de llamadas para que sea fácil ver dónde se encuentra
• Las variables se pueden modificar sobre la marcha.
• Los comandos adhoc se pueden ejecutar durante una pausa en la ejecución para ayudar al diagnóstico
• Se puede usar EN CONJUNCIÓN con sentencias de impresión: Debug.Write ("...")

Creo que la depuración con declaraciones impresas es un arte perdido y muy importante para que cada desarrollador aprenda. Una vez que sabe cómo hacer eso, ciertas clases de errores se vuelven mucho más fáciles de depurar 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 lo que es información útil para poner en un mensaje de registro (sin mencionar que en realidad terminarás leyendo el registro) también para fines de no 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 dejaré a las otras excelentes respuestas ya publicadas para explicar por qué :)

La parte superior de mi cabeza:

1. Depuración de objetos complejos : los depuradores le permiten adentrarse en las entrañas de un objeto. Si su objeto tiene, digamos, una matriz de objetos complejos, las declaraciones de impresión solo lo llevarán hasta cierto punto.
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, también podría hacerlo manualmente, pero es mucho más código el que debe inyectar.

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

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

No he estado desarrollando durante casi 20 años, pero encuentro que usando un IDE / depurador puedo:

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

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:

• defina puntos de interrupción condicionales (se interrumpe solo si se cumple una condición, o solo en el enésimo momento en que se ejecuta la instrucción en el punto de interrupción)
• interrumpir una excepción no controlada o siempre que se produzca una excepción (específica)
• cambiar variable durante la depuración
• repetir un fragmento de código configurando la siguiente línea que se ejecutará
• etc.

Además, cuando utilice el depurador, no tendrá que eliminar todas sus declaraciones de impresión una vez que haya finalizado la depuración.

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

printfla depuración puede funcionar bastante 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 lanzado para ayudar a diagnosticar los problemas del cliente.

Como se señaló en casi todas las otras respuestas aquí, lo mejor de un depurador estándar es que le permite examinar más fácilmente (y potencialmente cambiar) los detalles del estado del programa. No tiene que saber de antemano qué es lo que desea mirar: todo está disponible a su alcance (más o menos).

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 por uno y es imposible regresar si de repente quiere ver lo que sucedió antes. Esto está completamente en desacuerdo con el funcionamiento de nuestro cerebro. El cerebro recopila información y gradualmente forma una opinión. Puede ser necesario repetir los eventos varias veces para hacerlo, pero una vez que haya superado cierto punto, no podrá regresar.

En contraste con esto, una serie seleccionada de impresiones / registro le brinda una "proyección espacial de los eventos temporales". Le da una historia completa de lo que sucedió, y puede retroceder y cuarto varias veces muy fácilmente simplemente desplazándose hacia arriba y hacia abajo. Facilita responder preguntas como "¿ocurrió A antes de que ocurriera B"? 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 cierto bloqueo.

Sin embargo, cuando nos acercamos a problemas más difíciles en los que está involucrado un cambio gradual de estado. Donde, por ejemplo, un algoritmo corrompió una estructura de datos, eso a su vez causó que fallara un algoritmo de otro. O si queremos responder preguntas como "con qué frecuencia sucede esto", "las cosas suceden en el orden y en la forma en que imagino que sucedan". etc. Luego, la técnica de registro / impresión "antiguo" tiene una clara ventaja.

Lo mejor es usar cualquiera de las técnicas cuando sea más adecuado, por ejemplo, usar el registro / impresiones para llegar a algunos errores, y hacer una pausa en un punto de interrupción donde necesitamos explorar el estado actual con más detalle.

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

Debido a que la depuración de aplicaciones de subprocesos múltiples con declaraciones impresas te volverá loco. Sí, todavía puede hacerlo con declaraciones 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 solo tienen un solo hilo desafortunadamente

Como solicitó sugerencias para libros ... En lo que respecta a la depuración de Windows, John Robbins tiene varias ediciones de un buen libro sobre depuración de Windows:

Depuración de aplicaciones para Microsoft .NET y Microsoft Windows

Tenga en cuenta que la edición más reciente ( Depuración de aplicaciones Microsoft .NET 2.0 ) es solo .NET, por lo que es posible que desee una más antigua (como en el primer enlace) si desea la depuración de código nativo (cubre tanto .NET como nativo).

Personalmente, creo que la respuesta es tan simple como "Un depurador / IDE integrado le brinda una gran cantidad de información diferente rápidamente sin la necesidad de introducir comandos. La información tiende a estar frente a usted sin que usted no le haya dicho 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 línea de comandos o la depuración "printf".

Ventajas de un depurador sobre un printf ( tenga en cuenta no un depurador IDE sino cualquier depurador )

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

2. Puede depurar un binario que no puede volver a compilar en este momento

3. Puede depurar un binario que lleva mucho tiempo volver a compilar

4. Puede cambiar variables sobre la marcha

5. Puede llamar funciones sobre la marcha

6. No tiene el problema de que las redes de estado de depuración no se vacíen y, por lo tanto, el problema de sincronización no se puede depurar con precisión

7. Los depuradores ayudan con los volcados del núcleo, las declaraciones de impresión no

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

• Pila de llamadas, que también es una excelente manera de descubrir el código de otra persona
• Locales y relojes.
• Ventana inmediata, que es básicamente una consola C # y también me permite cambiar contenidos variables, inicializar cosas, etc.
• La capacidad de omitir una línea, configura la siguiente instrucción para que se ejecute en otro lugar.
• La capacidad de pasar el mouse sobre las variables y tener una información sobre herramientas que me muestra 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 más o menos WYSIWYG.

• Un depurador puede adjuntarse a un proceso en ejecución

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

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

Las declaraciones impresas pueden ser excelentes, pero arrojar tanta información a la pantalla en cualquier lugar 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 declaraciones impresas 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, increíblemente maravillosos para lenguajes administrados como Java o C #, son bastante útiles para C ++, y no son muy útiles para lenguajes de script como Python (pero podría ser que simplemente no he probado un buen depurador para cualquier lenguaje de script todavía).

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

Como alguien dijo anteriormente: ¡Depurador! = IDE.

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

Además, aunque la codificación C / ++ es más rara, las declaraciones printf a veces ocultan el error que está tratando de encontrar. (problemas de inicialización en vars automáticos 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 estaba bajo DOS :-)

TMTOWTDI

Además de mucho de lo que han dicho los otros carteles, realmente me gusta pasar 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 tienes esta habilidad.

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

¿Es esta una pregunta real del verdadero programador?

Cualquiera que haya pasado incluso 5 minutos depurando con declaraciones impresas y depurando con IDE, ¡le OCURRIRÁ sin siquiera preguntar!

He usado impresiones e IDEs para depurar y preferiría depurar usando un IDE. El único momento para mí cuando eso no funciona es en situaciones críticas de tiempo (como depurar juegos en línea) donde se llena el código con declaraciones impresas y luego se miran los archivos de registro después de que se ha salido terriblemente mal. Luego, si aún no puede resolverlo, agregue más impresiones y repita.

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

Puede adjuntarlo a una aplicación remota (obviamente, compilada en modo DEPURACIÓN) e inspeccionar su estado volcando la salida del depurador a un archivo utilizando la teeutilidad POSIX . En comparación con printf, puede elegir dónde generar 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 impriman el estado requerido en cada punto de interrupción, iniciar el depurador de la consola fdb | tee output.logy recorrer algunos puntos de interrupción. Después de eso, puede imprimir el registro y analizar la información mediante una comparación exhaustiva del 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 a un depurador.

Bueno, otra cosa es que si te unes a un nuevo proyecto antiguo y nadie sabe realmente cómo está haciendo el código lo que está haciendo, entonces no puedes depurar haciendo eco de 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 XDebuging visual me ayuda a tener una idea de lo que está sucediendo y dónde, en absoluto.

Atentamente

Raffael

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 declaraciones printf supone que usted sabe en qué función reside el error. En muchos casos no lo hace, por lo que debe hacer algunas conjeturas y agregar declaraciones de impresión a muchas otras funciones para localizarlo. El error puede estar en el código marco o en algún lugar 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 momentos.

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

La depuración en un IDE es invaluable en un entorno donde los registros de errores y el acceso de 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 stderro stdout.

Un problema con el uso de declaraciones de impresión es que hace un desastre con su código. Es decir, tiene una función con 10 partes y sabe que falla en algún lugar, pero no está seguro de dónde. Entonces agrega 10 declaraciones de impresión adicionales para determinar dónde está el error. Una vez que haya encontrado y resuelto su error, ahora tiene que limpiar quitando todas esas declaraciones impresas. Quizás hagas eso. Tal vez lo olvide y termine en producción y la consola de su usuario esté llena de impresiones de depuración.

Wauw, ¿me gusta esta pregunta? Nunca me atreví a posarlo ...

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

• Tener un modelo mental sólido de mi código, incluida la administración de memoria
• Usar instrumentación (como las declaraciones impresas) para seguir lo que está sucediendo

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

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

No es solo depuración. Un IDE lo ayuda a construir un mejor software más rápido de muchas maneras:

• herramientas de refactorización
• Intellisense para hacer que la API sea más reconocible, o recordar la ortografía / caso exacto de elementos familiares (no es muy útil si ha usado el mismo sistema durante 15 años, pero eso es raro)
• ahorre escribiendo escribiendo autocompletando variables y nombres de clase
• encuentra ciertos tipos de errores incluso antes de comenzar a compilar
• Salta automáticamente a variables / métodos / declaraciones / definiciones de clase, incluso si no están en el mismo archivo o carpeta.
• Romper con excepciones no manejadas y manejadas

Podría seguir.