¿Cómo se depura sin un IDE? [cerrado]

Cada vez que busco un IDE (actualmente estoy jugando con Go), encuentro un hilo lleno de personas que recomiendan Vi, Emacs, Notepad ++, etc.

Nunca he hecho ningún desarrollo fuera de un IDE; Supongo que me han mimado. ¿Cómo se depura sin un IDE? ¿Estás limitado a solo iniciar sesión?

Mediante el uso de un depurador. En su mayor parte, esto también es 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 depuradores anteriores de Unix como dbx.

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

Como en otras áreas, el uso de un depurador desde la línea de comandos requiere aprender una sintaxis y un conjunto de comandos, pero trae mucha flexibilidad y capacidad de escritura. Por otro lado, si ya se siente cómodo trabajando en un editor como vim o emacs, es posible que su editor favorito tenga un complemento para su depurador favorito.

Utilicé un depurador durante varios años mientras escribía controladores de gráficos. Tenía una segunda computadora que ejecutaba el depurador contra la primera (porque la pantalla en la computadora principal no funcionaba cuando el controlador de gráficos estaba roto). Era crítico poder detener el código y avanzar hasta el punto donde colgué el hardware para saber lo que estaba sucediendo.

Para problemas puramente de software, encuentro que pensar en el problema y probar el sistema para obtener más información sobre el problema es mucho más útil que recorrer 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 de lo que podría con un depurador.

Los errores más difíciles generalmente se resuelven entendiendo el problema fuera de la computadora. Algunas veces con un pedazo de papel o pizarra, y otras veces la respuesta se revela mientras estoy haciendo otra cosa. Los errores más complicados se resuelven mirando cuidadosamente el código como jugar Where's Waldo. Todo lo demás parece más fácil con declaraciones impresas o declaraciones de registro.

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

Algunas personas usan gdb en la línea de comando o un complemento . También hay front-end GUI independientes para gdb, como DDD . Dependiendo de su idioma, hay GUI independientes de depuración específicas del idioma, 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 secreto sucio acerca de los IDE es que todos ellos merecen la pena, le permiten especificar un editor personalizado, por lo que puede usar partes del IDE para ciertas tareas, pero use un editor decente para editar. No es raro que solo active un IDE para usar su depurador, especialmente si eso es lo que todos sus colegas usan.

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 un fragmento de código. Muchos de estos también ofrecen instalaciones de depuración. El GHC para Haskell viene con GHCi que puede usarse para depurar interactivamente un programa en la línea de comando, de forma similar a como lo haría un IDE.

No entiendo por qué existe una aversión a la depuración con el uso de declaraciones printf. Hubo un tiempo en que tardó demasiado en recompilar y vincular un programa, pero hoy solo lleva unos segundos. Me resulta muy fácil depurar usando el tipo de salida cout, printf, qDebug (), etc. Las declaraciones Printf le dan un historial de ejecución de todo lo que hizo el programa, que puede analizar después del hecho, mientras que la ejecución en el depurador hace que tenga que recordar manualmente el flujo del programa a medida que se ejecuta. Con printf's, puede convertir el valor de las variables en unidades específicas, mostrarlas en hexadecimal, decimal, lo que sea. Las declaraciones printf pueden enumerar los nombres de las rutinas y variables, y los números de línea también. Puede enumerar solo ciertos elementos de la matriz en función de otras variables. Puedes seguir indirecciones. Puedes controlar la salida muy fácilmente, poner en contadores, solo imprimir ciertos momentos a través de un bucle, agregar y eliminar declaraciones de impresión a medida que depura, 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 que intente recordar todos los lugares por los que pasó manualmente, y tal vez tenga que escribir el contenido de las variables a medida que cambian con el tiempo, para descubrir lo que ha hecho el programa. Y finalmente, con las declaraciones printf puede dejarlas permanentemente, para que se activen y desactiven, para futuras depuraciones. Es mucho más fácil ver el historial de su programa escrito en un archivo que tratar de recordar todos los lugares por los que pasó manualmente, y tal vez tenga que escribir el contenido de las variables a medida que cambian con el tiempo, para descubrir qué programa ha hecho. Y finalmente, con las declaraciones printf puede dejarlas permanentemente, para que se activen y desactiven, para futuras depuraciones. Es mucho más fácil ver el historial de su programa escrito en un archivo que tratar de recordar todos los lugares por los que pasó manualmente, y tal vez tenga que escribir el contenido de las variables a medida que cambian con el tiempo, para descubrir qué programa ha hecho. Y finalmente, con las declaraciones printf puede dejarlas permanentemente, para que se activen y desactiven, para futuras depuraciones.

jimwise respondió la pregunta bastante bien, pero pensé que debería agregar que, si 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, incluido WinDBG, que es el equivalente de la GUI, cuando descarga el SDK de Windows.

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

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

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

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

No siempre tiene un depurador a mano. En producción, podría ser imposible ejecutar un depurador (Demonios, 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 lleva demasiado tiempo o tal vez simplemente no hay buenos depuradores disponibles.

Si ha estado codificando todo el tiempo utilizando la lógica y el registro de nivel de depuración / rastreo, simplemente puede ser 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 que un error reportado es un error en sus pruebas en lugar de en su código.

También hay printf. Puede ser útil crear una gran cantidad de "registros" y buscar a través de ellos, en lugar de detenerse para cada línea. Me resulta particularmente útil si puede modificar las clases de la biblioteca que no podría modificar en producción, por ejemplo, -Xbootclasspath/p:para hackear las clases de la biblioteca Java.

Acuerde que el mejor de los problemas puede resolverse lejos de la computadora con un lápiz y papel o simplemente pensando en el problema. Esto es más útil que usar depuradores en vivo. A menudo corrige su 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 examinarlo con más detalle.

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