|
in reply to Using the perl debugger to look at a renaming files function
Though you've watched the Ricardo Signes How to use the Perl debugger talk twice
(while I've not yet watched it once)
I'd just like to throw a general word of caution that becoming an expert in using the Perl debugger
may not be the best use of your time if your goal
is to improve as a developer.
A few debugger quotes from some famous programmers:
- merlyn : I'm not into debugging. I can't recall ever invoking the Perl debugger except to try out snippets of code at a prompt ... But never for debugging. (Larry is also like this, I'm told.) merlyn again : If the code the client throws at you needs a debugger to trace it through, I'd argue it's not maintainable.
- Linus Torvalds : I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line. (See also: Linus Torvalds wikiquote).
- Brian Kernighan and Rob Pike : As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two.
One reason is that it is easy to get lost in details of complicated data structures and control flow;
we find stepping through a program less productive than thinking harder and adding output statements
and self-checking code at critical places.
Clicking over statements takes longer than scanning the output of judiciously-placed displays.
It takes less time to decide where to put print statements than to single-step to the critical section of code,
even assuming we know where that is.
More important, debugging statements stay with the program; debugging sessions are transient.
- Rob Pike : Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
- Uncle Bob Martin : Using a debugger is a code smell. I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort.
- John Graham-Cumming : For me, a debugger is (almost) always the wrong tool. And people who habitually use debuggers are making a big mistake, because they don't truly understand their code. I suspect that the same people who use debuggers all the time, are the same people who don't unit test their code.
- Daniel Lemire. The author of Python, Guido van Rossum, has been quoted as saying that he uses print statements for 90% of his debugging.
- Damian Conway urges you to add new test cases before you start debugging. After all, if the original test suite didn't report this bug, then that test suite was broken ... so fix the test suite first by adding tests that cause it to fail ... once the test suite is detecting the problem correctly, then you'll be able to tell when you've correctly fixed the actual bug, because the tests will once again fall silent.
See Also
References Added Later
|
Re^2: Using the perl debugger to look at a renaming files function
by Aldebaran (Curate) on Feb 06, 2021 at 01:02 UTC
|
Linus Torvalds : I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line.
I find myself wanting to retort, but that's not the right spirit. My claim rather is that this fulfills Torvalds' criterion:
$ perl -d 1.debug.11.pl
Loading DB routines from perl5db.pl version 1.55
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(1.debug.11.pl:12): my $ts = "template_stuff";
DB<1> c
+
title is 1.debug.1
path1 is /home/hogan/6.scripts/1.debug.1
abs is /home/hogan/6.scripts/1.debug.1/1.debug.11.pl
debug1::make_initial_captions(template_stuff/debug1.pm:42):
42: my $iter = $image_path ->iterator;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image3.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image4.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image6.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image1.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image5.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image0.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
/home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image2.png
Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179):
1179: my $next;
DB<1> c
+
return2 is nothing yet
ini path is /home/hogan/Documents/html_template_data/6.values.ini
...
return is 1.debug.15.html
http://www.merrillpjensen.com/perlmonks/1.debug.15.html
Debugged program terminated. Use q to quit or R to restart,
use o inhibit_exit to avoid stopping after program termination,
h q, h R or h o to get additional info.
DB<1> q
+
$
All of the people you quote are elite professional programmers as opposed to the intermediate that I am, who makes useful software for his own communications, holding it all together with bubble-gum and tie-wire. I really like the price, too. Getting output adds to an already happy day....
| [reply]
[d/l] |
|
|
Though I've never met Linus, I suspect retorting to him would be futile,
given his parting shot was "Because I'm a bastard, and proud of it!". :)
Update: It seems Linus is now a reformed character (from Organizational Culture (Part V): Behavior).
Based on the code you posted, I feel the most relevant quotes for you
are from Pike, Martin, and especially Graham-Cumming:
I suspect that the same people who use debuggers all the time are the same people who don't unit test their code
and Conway:
fix the test suite first by adding tests that cause it to fail ... once the test suite is detecting the problem correctly, then you'll be able to tell when you've correctly fixed the actual bug, because the tests will once again fall silent
That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger.
I suggest you at least consider the option of replacing hours of never-ending crack-pipe debugging sessions
with enjoyable creative hours of Test Driven Development.
| [reply] |
|
|
That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger.
I don't think there's ever a need to fire up the debugger. However, there are occasions where a debugger session might just be the fastest way to narrow down an error. Unit tests and the debugger are by no means an either-or decision.
I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help.
The quotes about tracing (merlyn) or stepping through a program (Brian Kernighan and Rob Pike) just miss the point about what debuggers can do. Personally, I'd rather use the debugger than print statements (Daniel Lemire) just because debugging sessions are transient (Brian Kernighan and Rob Pike). I don't want to spend time to format data structures for printing (the debugger does it for free), and I don't want to have to remove the print statements before committing.
I agree with most of the quotes that you need to think before starting to debug. But I also think that you need to know the debugger to some extent to decide whether it is a good tool to tackle a problem or not. Learning the debugger is not a waste of time, and it is easier to get started with than e.g. Log::Log4perl or Test-driven development.
| [reply] |
|
|
|
|
|
|
