Post mortem debugging: My way…

Tem gente que acha que sou antiquado, quando se trata de ambientes de desenvolvimento e debuggers. Minha maneira de programar é essa: Abro uma interface de linha de comando (CLI, como um terminal, no Linux, ou o DOS Prompt, no Windows), edito os códigos-fonte com o VIM, crio um Makefile que usa o GCC, compilo os códigos chamando o make e executo o produto final.

Meus códigos-fonte ficam cheios de diretivas de pré-compilador para fazer o chamado post mortem debugging — quer dizer, debugging depois que o produto final está pronto. A partir dai é acertar os problemas, recompilar com o make e executar, de novo, e permanecer nesse ciclo até o trambolho todo funcionar como eu quero.

E quanto ao debugger de facto? Quando é que eu uso o GDB?! Quando não consigo encontrar o problema facilmente com minhas diretivas! Uso o GDB depois que a pergunta “por que diabos essa merda não tá funcionando?” passa pela minha cabeça…

Sou antiquado porque não recorro a ambientes gráficos (IDEs — Integrated Development Environments — como o Eclipse ou o Visual Studio). Não os uso porque gasto mais tempo aprendendo a usar essas aplicações do que fazendo aquilo que realmente me dispus a fazer: debugar!

Você pode argumentar que debuggers como o GDB requerem que o usuário aprenda um monte de comandos e que as IDEs tornam isso mais fácil, afinal, basta clicar aqui e ali. Só que o GDB é tão simples! E é fácil mostrar isso… Eis os comandos que um desenvolvedor tem que aprender a usar no GDB:

r = run
c = continue
b = breakpoint
n = next
s = step
p = print
l = list

Me diz ai… o que isso difere de atalhos como F5 (Run), F7 (Next), F6 (Step), no caso do Visual Studio? (well… pelo que me lembro, são esses!)

É claro que existem outras ferramentas no GDB (watches, breakpoints condicionais, etc), mas o uso dessas é tão simples quanto as ferramentas equivalentes numa IDE! Então, qual é a vantagem real em não usar uma IDE?

Primeiro, seu código não será executado em baixo de um caminhão de código proprietário. Não é porque é “proprietário”, mas porque é um caminhão de código! Tá certo que o GDB tem quase 4 MB de tamanho, mas compare isso ao Visual Studio (que deve ter uns 400 MB, ou mais, e deve ocupar bem mais que isso, na memória!). Quando sua aplicação é faminta por memória isso faz toda a diferença e, ainda mais, quando sua aplicação depende dos efeitos do cache de instruções, well… o GDB comporta-se melhor que uma IDE.

Outra vantagem, óbvia, é que não tenho que instalar um DVD inteiro de arquivos binários e configurações que bagunçam o meu sistema para debugar um programinha (o mesmo não pode ser dito do Visual Studio!).

Mas, hey, se você se dá bem com um IDE, vá em frente… Só que eu recomendo que você se familiarize com o GDB e use mais os recursos de sua linguagem para fazer um post mortem

Anúncios

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s