Have you every written a Perl program that doesn't perform as you would wish? Yes, everyone who's written a Perl program has done that. Once any syntax errors have been corrected, you run your program for the first time and you check - VERY carefully - the results. Any errors, and the patterns of errors, will often lead you quickly to coding errors and as you gain experience, you'll fix more and more bugs quicker and quicker this way.
But what about those 'reluctant' bugs - those things that have you scratching you head thinking "surely this cannot be happening". You need further clues, and Perl offers a number of facilities - some very simple - to help you.
1. You should run your code with the -w command line option, or with
specified at the top of your code. Both of these operations cause Perl to check at both compile and run time that you're not specifying something that's technically valid, but unlikely to be what you intended - it'll pick you up on uninitialised variables, variable names that only occur once, bare words that should probably have a $ in front of them, and so on.
2. The humble print
statement can be very revealing - add in a few extra output statements for intermediate variables and you'll soon start to see where abouts in your code its behaviour starts to deviate from what you had intended.
3. The Data::Dumper
module allows you to "pretty print" data structures if you want to go beyond the print statement - perhaps you have whole lists or hashes that you want to dump out? (Link - source example using Data::Dumper
4. Perl comes with an interactive debugger - run Perl with the -d option if you want to run this way. There's a tutorial on this in the perl distribution - run perldoc perldebtut
at the command line for more details.
If these initial four ideas don't cut it for you, there are other things to consider too.
Personally, if I'm writing a difficult piece of code I will start off with
$trace = 0;
at the top, and further down my code I'll add in statements such as
$trace and print "At point X, counter is $n, total $tot\n";
which form a report / debug facility if run; all I need to do is to switch my initial assignment to a true value, and I've turned on a tailored debugging mode. We use a similar technique on our web site pages under both PHP and Perl - where we accumulate reports using the .= operator and output them at the end of our web pages - users rarely notice and it's sometimes a huge help to us when we're looking to resolve browser specific issues or data driven problems.
Some advocates suggest that you should
in all your code as a debug tool. I'm going to disagree. Rather, it is good practise to use the strict pragma in all .pm files that you'll be including but that should be as a matter of course and not just as a debugging aid. And I will typically omit the pragma from my main code / main program.
There's various CPAN modules to help you too - ptkdb and Devel::ebug provide a GUI to help debug, and programatic hooks for you to add your own debug facilities, if that's what you want.
And finally, there are commercial debuggers such as ActiveState's Komodo.
My own favourite toolkit - what I suggest to course delegates ...
a) Comment your code well, use sensible variable names to reduce bugs in the first place.
b) Think about your code - design it well (if informally) with appropriate UML diagrams to reduce design errors in the first place. (Link - .pdf training module on this
c) Run with the -w
command line option at least a few times.
d) use strict;
e) Add in print or Data::Dumper calls, perhaps under a $trace option, if you've got a piece of large / complex / reluctant code.
The other options? Great to have them available from time to time ... (written 2006-06-04, updated 2006-06-05)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesP050 - Perl - General 
Perl - still a very effective language indeed for extracting and reporting - (2014-09-20) 
Polishing the Perl courses - updated training - (2014-09-17) 
How well do you know Perl and / or Python? - (2012-11-04) 
Shell - Grep - Sed - Awk - Perl - Python - which to use when? - (2012-10-22) 
Know Python or PHP? Want to learn Perl too? - (2012-07-31) 
Perl - a quick reminder and revision. Test yourself! - (2011-08-26) 
DNA to Amino Acid - a sample Perl script - (2011-06-24) 
How much has Perl (and other languages) changed? - (2011-06-10) 
How many toilet rolls - hotel inventory and useage - (2010-12-18) 
Should the public sector compete with businesses? and other deep questions - (2010-09-26) 
Perl course - is it tailored to Linux, or Microsoft Windows? - (2010-06-25) 
The Perl Survey - (2010-05-27) 
Perl Course FAQ - (2010-04-23) 
Learning to program in ... - (2009-11-15) 
Lead characters on Perl variable names - (2009-08-24) 
So what is this thing called Perl that I keep harping on about? - (2009-06-15) 
Where do I start when writing a program? - (2009-06-11) 
Keeping on an even keel - (2008-11-21) 
Glorious (?) 12th August - what a Pe(a)rl! - (2008-08-12) 
New in the shops - (2005-08-01) 
The next generation of programmer - (2004-11-13)P201 - Perl - Introduction 
Are you learning Perl? Some more examples for you! - (2010-06-27) 
What is Perl? - (2010-06-15) 
Converting to Perl - the sort of programs you will write - (2009-03-08) 
Perl and Blackberries - (2008-10-23) 
Perl v PHP, choosing the right language - (2008-08-14) 
Q - Should I use Perl or Python? - (2008-07-23) 
The LAMP Cookbook - Linux, Apache, MySQL, PHP / Perl - (2006-11-13) 
Is Perl being replaced by PHP and Python? - (2006-08-27) 
Testing you Perl / PHP / MySQL / Tcl knowledge - (2006-04-19) 
Choosing the right language - (2006-03-01) 
Perl - multiprocess applications - (2006-02-13) 
Twice is a co-incidence and three times is a pattern - (2006-02-07) 
Learning to program in Perl or PHP - (2006-01-26) 
Central London Courses - Perl, PHP, Python, Tcl, MySQL - (2005-07-18) 
Programming languages - a comparison - (2005-05-20) 
Release numbers - (2004-08-23)P203 - More about the Perl Environment 
Different perl examples - some corners I rarely explore - (2010-07-18) 
Debugging and Data::Dumper in Perl - (2008-11-02) 
Getting rid of variables after you have finished with them - (2006-06-06) 
Making programs easy for any user to start - (2005-05-29)P222 - Perl - Programming Efficiency and Style 
Hungarian, Camel, Snake and Kebab - variable naming conventions - (2016-01-03) 
Security considerations in programming - what do we teach? - (2010-03-22) 
Want to do a big batch edit? Nothing beats Perl! - (2010-03-01) 
Firefighting with Perl - (2009-09-07) 
Good Programming practise - where to initialise variables - (2007-05-09)P711 - An Introduction to Standards in Perl 
Learning to program - comments, documentation and test code - (2014-11-22) 
Perl - making best use of the flexibility, but also using good coding standards - (2011-08-19) 
A long day in Melksham ... - (2010-07-17) 
Designing your data structures for a robust Perl application - (2009-08-25) 
About dieing and exiting in Perl - (2008-11-01) 
Well structured coding in Perl - (2008-10-24) 
A short Perl example - (2008-07-30) 
Advanced Python, Perl, PHP and Tcl training courses / classes - (2008-02-25) 
Dont just convert to Perl - re-engineer! - (2007-10-18) 
Perl and Shell coding standards / costs of an IT project - (2007-09-11) 
Bathtubs and pecking birds - (2007-06-07) 
Maintainable code - some positive advice - (2007-01-21) 
KISS - one action per statement please - Perl - (2006-12-05) 
Code quality counts - (2006-11-26) 
Python - block insets help with documentation - (2006-04-04) 
Satisfaction of training - (2005-03-11)
Some other Articles
The Fag Packet Design MethodologyDomain Listing Center and Domain Registry of AmericaPython modules. The distribution, The Cheese Shop and the Vaults of Parnassus.We can offer a room, but we can't operate on a dogHow to debug a Perl programA visit from the solicitorLast week - picture of the Perl courseFinishing up in DhahranThe eye(Perl) Callbacks - what are they?