¿Cómo se realiza la depuración sin un IDE? [cerrado]

Usando un depurador. En su mayor parte, esto es también lo que hace un IDE detrás de escena: simplemente envuelve la experiencia en una GUI.

En Unix, uno de los depuradores más utilizados es GNU gdb , que ha suplantado en gran medida a los anteriores depuradores Unix, como dbx .

Para tener una idea de cómo se ve / se siente la depuración desde la línea de comandos, puede mirar el manual de gdb .

Al igual que en otras áreas, usar un depurador desde la línea de comandos requiere aprender una sintaxis y un conjunto de comandos, pero trae consigo un lote de flexibilidad y capacidad de escritura. Por otro lado, si ya te sientes cómodo trabajando en un editor como vim o emacs, puedes encontrar que tu editor favorito tiene un complemento para tu depurador favorito.

Utilicé un depurador durante varios años mientras escribía controladores de gráficos. Tuve una segunda computadora que ejecutó el depurador contra la primera (porque la pantalla de la computadora principal no funcionaría cuando el controlador de gráficos estaba roto). Fue fundamental poder detener el código y pasar al punto donde colgué el hardware para que supiera lo que estaba pasando.

Para los problemas puramente de software, me parece que pensar en el problema y probar el sistema para aprender más sobre el problema es mucho más útil que pasar el código línea por línea. Con las declaraciones de impresión, tengo una lista de todo lo que sucedió en la línea de comandos o en el archivo de registro que puedo ver y reconstruir lo que sucedió, yendo hacia atrás y hacia adelante con más facilidad que nunca con un depurador.

Los errores más difíciles generalmente se resuelven al entender el problema lejos de la computadora. A veces con un trozo de papel o una pizarra, y otras veces la respuesta se revela mientras hago otra cosa. Los errores más complicados se resuelven observando cuidadosamente el código, como jugar Where's Waldo. Todo lo demás parece más fácil con las declaraciones impresas o las declaraciones de registro.

Diferentes personas tienen diferentes estilos y diferentes estilos son mejores para diferentes tareas. Las declaraciones de impresión no son necesariamente un paso hacia abajo de un depurador. Dependiendo de lo que estés haciendo, incluso pueden ser mejores. Especialmente en un idioma que no tiene un depurador nativo (hace Go?).

Algunas personas usan gdb en la línea de comandos, o a plugin . También hay front-end GUI independientes para gdb, como DDD . Dependiendo de su idioma, hay GUI independientes del depurador de idioma específico, como Winpdb para python, o jswat para java. Debido a que estos proyectos se centran solo en la depuración, a menudo son superiores a los depuradores integrados.

El otro pequeño y sucio secreto de los IDE es que todos ellos valen la pena porque le permiten especificar un editor personalizado, por lo que puede usar partes del IDE para ciertas tareas, pero usar un editor decente para editar. No es raro que solo se active un IDE para usar su depurador, especialmente si es lo que usan todos sus colegas.

Algunos idiomas ofrecen un REPL, es decir, puede escribir y ejecutar código línea por línea a medida que lo escribe, lo que puede ser un primer paso para verificar una parte del código. Muchos de estos también ofrecen instalaciones de depuración. El GHC para Haskell viene con GHCi que se puede usar para depurar interactivamente un programa en la línea de comandos, de manera similar a como lo haría un IDE.

No entiendo por qué hay una aversión a la depuración con el uso de sentencias printf. Hubo un tiempo en el que demoró demasiado en compilar y vincular un programa, pero hoy solo toma unos segundos. Me resulta muy fácil de depurar utilizando el tipo de salida cout, printf, qDebug (), etc. Las declaraciones de Printf le brindan un historial de todo lo que hizo el programa, que puede analizar después del hecho, mientras que ejecutarlo en el depurador hace que tenga que recordar manualmente el flujo del programa mientras se ejecuta. Con printf's, puedes convertir el valor de las variables en unidades específicas, mostrarlas en hexadecimal, decimal, lo que sea. Las declaraciones de printf pueden enumerar los nombres de las rutinas y variables, y también los números de línea. Puede listar solo ciertos elementos de la matriz dependiendo de otras variables. Puedes seguir indirecciones. Puede controlar la salida muy fácilmente, poner contadores, solo imprimir ciertas veces a través de un bucle, agregar y eliminar declaraciones de impresión a medida que realiza la depuración, tener diferentes niveles de salida de depuración, escribir en archivos, etc. Es mucho más fácil ver el historial de su programa escrito en un archivo para tratar de recordar todos los lugares por los que caminó manualmente, y tal vez tenga que anotar el contenido de las variables a medida que cambian con el tiempo, para descubrir qué ha hecho el programa. Y, por último, con las declaraciones de printf puede dejarlas permanentemente, para activarlas y desactivarlas, para futuras depuraciones.

jimwise respondió la pregunta bastante bien, pero pensé que debería agregar eso, debería elige trabajar sin un IDE completo, el depurador de línea de comandos proporcionado por Microsoft para Windows se llama CDB . CDB viene con varias otras herramientas, incluyendo WinDBG , que es la Equivalente de GUI, cuando descarga el SDK de Windows.

Normalmente no uso un depurador, tal vez una vez cada dos semanas, pero no es lo primero a lo que voy.

La herramienta más importante en mi trabajo es tan ubicua que casi me olvido de mencionarla: apilar rastros. Más del 90% de los problemas que encuentro pueden resolverse examinando una traza de pila. Esta herramienta no siempre es muy útil dependiendo de su idioma, pero cuando se implementan bien con un idioma, pueden ahorrarle una cantidad de tiempo increíble.

Supongo que la segunda forma más común en que detecto problemas simples es que probablemente sea el código que acabo de cambiar. Hago pruebas de unidad con bastante frecuencia, así que generalmente sé lo que acabo de romper.

Para un desarrollo y depuración más complejos, puedo agregar algunas declaraciones de registro de depuración o nivel de seguimiento. Considero que los problemas de desarrollo son una buena guía para ayudarme a colocar información de registro de seguimiento / depuración de producción, lo que me lleva a:

No siempre tienes a mano un depurador. En producción, podría ser imposible ejecutar un depurador (Heck, podría ser imposible acceder a las máquinas de producción, excepto los registros, según la seguridad de su empresa). También hay idiomas en los que conectar un depurador solo toma demasiado tiempo o tal vez no haya buenos depuradores disponibles.

Si ha estado codificando todo el tiempo utilizando la lógica y el registro de nivel de depuración / seguimiento, puede ser simplemente el caso de examinar sus excelentes declaraciones de registro (posiblemente aumentando el nivel de registro) para resolver el problema sin siquiera acceder al hardware.

Aunque creo que los depuradores son una herramienta poderosa, ¡no dejes que sean la única herramienta en tu caja de herramientas!

No hay ninguna razón por la que no pueda usar el depurador en un IDE junto con un editor de texto independiente. Solía usar! Zap para editar, JBuilder para depurar en otra máquina y un servidor de archivos en el sótano. Tradicionalmente, los depuradores eran programas independientes sin arrastrar un IDE, y eso también funciona.

Vale la pena notar que las pruebas exhaustivas desplazan la depuración. Vale la pena considerar un error reportado como un error en sus pruebas en lugar de en su código.

También hay printf . Puede ser útil crear una gran cantidad de "registro" y buscar a través de él, en lugar de detener cada línea. Me parece especialmente útil si puede modificar las clases de biblioteca que no podría modificar en producción, por ejemplo, utilizando -Xbootclasspath/p: para piratear las clases de biblioteca de Java.

Acepte que el mejor de los problemas se puede resolver fuera de la computadora con un lápiz y papel o simplemente pensando en el problema. Esto es más útil que el uso de depuradores en vivo. A menudo corrige tu proceso de pensamiento.

Puede usar pudb que es una consola basada en una interfaz de usuario simple. Puede elegir su depurador preferido como pdb o ipdb si desea ingresar un REPL y examinar con más detalle.

También consulte PythonDebuggingTools para obtener una colección más completa de las herramientas disponibles.