Como você depura sem um IDE? [fechadas]

Usando um depurador. Na maior parte, isso também é o que um IDE faz nos bastidores - apenas envolve a experiência em uma GUI.

No Unix, um dos depuradores mais usados é o GNU gdb , que em grande parte suplantou os depuradores anteriores do Unix, como dbx .

Para ter uma ideia de como é a depuração na linha de comando, você pode consultar o manual do gdb .

Como em outras áreas, usar um depurador na linha de comando requer aprender uma sintaxe e um conjunto de comandos, mas traz consigo um lote de flexibilidade e scriptabilidade. Por outro lado, se você já está confortável trabalhando em um editor como o vim ou o emacs, você pode descobrir que seu editor favorito tem um plug-in para o seu depurador favorito.

Eu usei um depurador por vários anos enquanto escrevia drivers gráficos. Eu tinha um segundo computador que executava o depurador contra o primeiro (porque a tela no computador principal não funcionava quando o driver gráfico estava quebrado). Era essencial poder parar o código e ir ao ponto em que pendurei o hardware, para saber o que estava acontecendo.

Para problemas puramente de software, acho que pensar no problema e testar o sistema para aprender mais sobre o problema é muito mais útil do que percorrer o código linha por linha. Com as declarações de impressão, eu tenho uma lista de tudo o que aconteceu na linha de comando ou arquivo de log que eu posso ver e reconstruir o que aconteceu, indo para trás e para frente mais facilmente do que eu poderia com um depurador.

Os erros mais difíceis geralmente são resolvidos pela compreensão do problema longe do computador. Às vezes com um pedaço de papel ou quadro branco, e às vezes a resposta se revela enquanto estou fazendo outra coisa. Os erros mais complicados são resolvidos observando atentamente o código, como jogar Where's Waldo. Todo o resto parece mais fácil com instruções de impressão ou declarações de registro.

Pessoas diferentes têm estilos diferentes e estilos diferentes são melhores para tarefas diferentes. Declarações de impressão não são necessariamente um passo abaixo de um depurador. Dependendo do que você está fazendo, eles podem até ser melhores. Especialmente em uma linguagem que não possui um depurador nativo (o Go?).

Algumas pessoas usam o gdb na linha de comando, ou um plugin . Há também front ends GUI independentes para o gdb, como o DDD . Dependendo do seu idioma, existem GUIs de depuração autônomas específicas do idioma, como Winpdb para python, ou jswat para java. Como esses projetos enfocam somente na depuração, eles geralmente são superiores aos depuradores integrados.

O outro pequeno segredo sujo sobre os IDEs é que todos eles valem a pena permitir que você especifique um editor personalizado, para que você possa usar partes do IDE para determinadas tarefas, mas use um editor decente para edição. Não é incomum apenas abrir um IDE para usar seu depurador, especialmente se é isso que seus colegas usam.

Algumas linguagens oferecem um REPL - ou seja, você pode escrever e executar o código linha por linha à medida que você o escreve, o que pode ser um primeiro passo na verificação de uma parte do código. Muitos deles também oferecem recursos de depuração. O GHC para Haskell vem com o GHCi, que pode ser usado para depurar interativamente um programa na linha de comando, semelhante ao que um IDE faria.

Eu não entendo porque existe uma aversão à depuração com o uso de instruções printf. Houve um tempo em que demorou muito para recompilar e vincular um programa, mas hoje leva apenas alguns segundos. Eu acho muito fácil depurar usando cout, printf, qDebug (), etc. tipo de saída. As instruções Printf fornecem um histórico de execução de tudo o que o programa fez, que você pode analisar após o fato, enquanto a execução no depurador faz com que você precise lembrar manualmente o fluxo do programa durante a execução. Com printf's, você pode converter o valor das variáveis em unidades específicas, exibi-las em hexadecimal, decimal, o que for. As instruções printf podem listar os nomes das rotinas e variáveis e os números das linhas também. Você pode listar apenas determinados elementos da matriz, dependendo de outras variáveis. Você pode seguir indiretamente. Você pode controlar a saída com muita facilidade, colocar em contadores, imprimir apenas algumas vezes através de um loop, adicionar e remover instruções de impressão à medida que você depura, ter diferentes níveis de saída de depuração, gravar arquivos etc. É muito mais fácil ver o histórico de seu programa escrito em um arquivo do que tentar lembrar de todos os lugares que você percorreu manualmente, e talvez tenha que anotar o conteúdo das variáveis conforme elas mudam ao longo do tempo, a fim de descobrir o que o programa fez. E, finalmente, com instruções printf você pode deixá-las permanentemente, para serem ativadas e desativadas, para depuração futura.

jimwise respondeu a questão muito bem, mas eu pensei que deveria acrescentar isso, deveria Se você optar por trabalhar sem um IDE completo, o depurador de linha de comando do Windows fornecido pela Microsoft será chamado CDB . O CDB vem com várias outras ferramentas, incluindo WinDBG , que é o Equivalente à GUI, quando você faz o download do SDK do Windows.

Eu não costumo usar um depurador, talvez uma vez a cada duas semanas, mas não é a primeira coisa que eu vou.

A ferramenta mais importante no meu trabalho é tão onipresente que quase me esqueci de mencioná-la - rastreamentos de pilha. Mais de 90% dos problemas que encontro podem ser resolvidos examinando-se um rastreamento de pilha. Esta ferramenta nem sempre é muito útil, dependendo do seu idioma, mas quando elas são implementadas por um idioma, elas podem economizar uma incrível quantidade de tempo.

Eu acho que a segunda maneira mais comum de detectar problemas simples é que provavelmente é o código que acabei de alterar. Eu corro testes de unidade com bastante frequência, então eu geralmente sei o que acabei de quebrar.

Para desenvolvimento e depuração mais complexos, devo adicionar algumas instruções de log no nível de depuração ou de rastreio. Eu considero problemas de desenvolvimento um bom guia para me ajudar a colocar informações de registro de rastreio / depuração de produção, o que me leva a:

Você nem sempre tem um depurador à mão. Na produção, pode ser impossível executar um depurador (Heck, pode ser impossível acessar as máquinas de produção, exceto os logs, dependendo da segurança da sua empresa). Existem também idiomas onde a conexão de um depurador demora muito tempo ou talvez simplesmente não haja bons depuradores disponíveis.

Se você tem codificado o tempo todo usando lógica e log de nível de depuração / rastreio, pode simplesmente ser o caso de examinar suas excelentes instruções de log (possivelmente aumentando o nível de log) para descobrir o problema sem acessar o hardware.

Embora eu ache que os depuradores são uma ferramenta poderosa, não os deixe ser a única ferramenta na sua caixa de ferramentas!

Não há motivos para não usar o depurador em um IDE ao lado de um editor de texto independente. Eu costumava usar! Zap para editar, JBuilder para depurar em outra máquina e um servidor de arquivos no porão. Tradicionalmente depuradores eram programas independentes sem arrastar ao longo de um IDE, e isso funciona também.

Vale a pena notar que testes abrangentes substituem a depuração. Vale a pena considerar um bug reportado como sendo um bug no seu teste, e não no seu código.

Há também printf . Pode ser útil criar uma grande quantidade de "registro" e pesquisar por meio dele, em vez de parar para cada linha. Eu acho particularmente útil se você pode modificar classes de biblioteca que você não seria capaz de modificar em produção, por exemplo, usando -Xbootclasspath/p: para hackear classes de bibliotecas Java.

Você pode usar o pudb , que é um console baseado em uma interface de usuário simples. Você pode escolher o seu depurador preferido, como pdb ou ipdb, se quiser inserir um REPL e examinar com mais detalhes.

Além disso, verifique a PythonDebuggingTools Wiki para obter uma coleção mais abrangente de ferramentas disponíveis.