Three Thoughts on Developer Tools

October 12, 2008
The first two ideas are meant for developers trying to understand a code base they haven’t seen before.
  1. Run a program. Keep track of which lines of code get hit and count how many times. In the source code editor, colour by use. Help the developer focus on the important stuff. (Inspired by the performance profiling line-by-line heat map I once saw in XCode.) Advanced version: Save this information and link to test cases, so it’s easy to look at the code that a test case hits. 
  2. Run a program. For variables that get used in control statements, keep track of the domain of those variables during program execution. This would make it easy to catch some fencepost errors and also see why control statements ran the way they did, without stepping through in the debugger. 
  3. Novice programmers test their programs by running them again and again and typing in the input again and again. They use print statements to debug. Automated tests are better and not much more work. We need a way to turn a program execution with typed-in input into a high-quality automated test cases. Macros don’t cut it. This is hard but solving it is valuable. (This one has been done, but as far as I know, not yet done well.)

One Response to “Three Thoughts on Developer Tools”

  1. Ian Says:

    We use tprof to do performance analysis and identify hot spots in the code. It is capable of producing line-level info, but typically we summarize it up to function level information to make it more consumable. Certainly more tightly integrating tprof would be very useful.

    I guess I’m not a complete novice … while I use printf for prototyping crude/prototype traces, I at least automate the invocations using very short-named scripts 🙂

Comments are closed.

%d bloggers like this: