Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • About the only time I drop into a debugger these days is to do some exploratory testing, or to play with somebody else's code.

    I've actually noticed a new pattern in my coding style since I started doing TDD. I delete the code I have just written when I unexpectedly fail a test without bothering to figure out what caused the bug - let alone dropping into a debugger. It's quicker to rewrite it correctly than it is to figure out what I did wrong :-)
  • I learned programming before debuggers became available. My theory was "understand what you write, never outwrite ahead of your brain". And when that failed, "add print until it works".

    I never realized how much this influences my coding style until I was recently in front of 30 people at a client location, writing some complex code in real time for them. I'd write three or four lines of code, run the program, then either rewrite those three or four lines if they didn't do what I expect, or I'd write th

    • Randal L. Schwartz
    • Stonehenge
    • My counter to this would be that you're often debugging *someone else's* code, and that's where debuggers can be a lifesaver, or simply help you find a bug in someone's module on CPAN.

      I sometimes use a debugger as a way to graphically represent complex data structures that I don't understand and I'm not sure how deeply nested they are (i.e. where print statements won't necessarily work).

      But on the whole, yes, they can make you lazy.

    • I guess this small-steps way of doing things kind of requires a language like Perl where you essentially have no compilation step to prevent you from seeing what you just did.

      In a way it resembles the way of writing HTML: write, save, switch to the browser and reload in a quick sequence.

      So using a language which takes longer to compile, like C++ in a lot of cases, breaks the cycle, forcing you to write more and more code to justify a compilation (thereby verifying that you didn't outwit yourself).
      • Yeah, quick turnaround on the compile/link/run cycle is essential. I've been able to do Test Driven Development in Perl, Java, and now Python, but have thus far avoided the opportunity of trying it in C++.

        It's amazing how comforting it is to know that if you find a problem, changes are really good that you caused it within the last few minutes, and that you only have to take one step back.

        • Anyone with success stories of TDD in C++?

          I'm think I'm about to get involved in that in the near future, and I'd appreciate any practical tips and tricks.