ds****@hotmail.com (markus) wrote in message news:<bc**************************@posting.google. com>...
Hi,
Examples of such tools are cscope, cbrowser, tags, etc.
...
There are ofcourse many different levels of programmers, and the
beginners might only use emacs or vi to write their code. However,
since there are such great tools out there to help the programmer
I find ctags more useful than cscope in general. In particular I use
the ctags formerly bundled with Vim (exuberant ctags) (off-topic:
works well with other languages too, as diverse as ASP, Python, Java,
Scheme, and Fortran to name a few). And of course find and grep are
incredibly useful on large source trees.
make integration with the editor (as vim and emacs do naturally) is
nice.
Anyway, I find that 98% or more of development is done with a simple
editor and compiler. Other useful tools:
gdb (or whatever your debugger of choice is). You can pretty easily
wire it up so that a segfault (SIGSEGV) fires up a debugger, attaches
to the current process, and gives a stack trace. Can be somewhat
handy.
strace (or truss) to trace system calls
ltrace to trace library calls
For some applications, lsof and netstat (to list open files and
network sockets)
ElectricFence, a memory debugger. Very handy if you've got memory
problems (those mysterious segfaults usually get moved up to where
invalid memory access first happened)
The Boehm-weiser garbage-collecting malloc implementation can be
compiled in a memory leak detection mode that I've found helpful a
couple of times (especially if you're debugging a big third-party app
with memory leaks)
CVS or Subversion (or equivalent); I find it useful to version my
files even when I'm working alone, so I can more freely try out
different approaches.
I still find myself doing printf debugging most of the time (to the
point that I get familiar with http -X for large web applications or
equivalent ways of making sure I can run synchronously and on
console).
And of course, getting a second pair of eyeballs to look at things is
handy.
Failing that, it's useful to pretend you're writing to a newsgroup for
advice and go through all the steps they would ask you for ("They're
going to want a minimal test case. Okay, I'll write one. They're
going to ask if I've tried this edge case. Okay, done. They're going
to ask if I've tried this edge case. Okay, done."). It's amazing how
often I can find a bug that I've spent a half hour or more chasing if
I just sit down and approach it from that perspective ("They're going
to ask if I've tried passing zero to that function--oh, wait, that's
not right. Duh, what a stupid bug.").
Worst case you can post a message that has the minimal test case and a
list of all the things you've tried.
