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 articlesP711 - An Introduction to Standards in Perl 
Satisfaction of training - (2005-03-11) 
Python - block insets help with documentation - (2006-04-04) 
Code quality counts - (2006-11-26) 
KISS - one action per statement please - Perl - (2006-12-05) 
Maintainable code - some positive advice - (2007-01-21) 
Bathtubs and pecking birds - (2007-06-07) 
Perl and Shell coding standards / costs of an IT project - (2007-09-11) 
Dont just convert to Perl - re-engineer! - (2007-10-18) 
Advanced Python, Perl, PHP and Tcl training courses / classes - (2008-02-25) 
A short Perl example - (2008-07-30) 
Well structured coding in Perl - (2008-10-24) 
About dieing and exiting in Perl - (2008-11-01) 
Designing your data structures for a robust Perl application - (2009-08-25) 
Security considerations in programming - what do we teach? - (2010-03-22) 
A long day in Melksham ... - (2010-07-17) 
Perl - making best use of the flexibility, but also using good coding standards - (2011-08-19) 
Learning to program - comments, documentation and test code - (2014-11-22)P222 - Perl - Programming Efficiency and Style 
Good Programming practise - where to initialise variables - (2007-05-09) 
Firefighting with Perl - (2009-09-07) 
Want to do a big batch edit? Nothing beats Perl! - (2010-03-01) 
Hungarian, Camel, Snake and Kebab - variable naming conventions - (2016-01-03)P203 - More about the Perl Environment 
Making programs easy for any user to start - (2005-05-29) 
Getting rid of variables after you have finished with them - (2006-06-06) 
Debugging and Data::Dumper in Perl - (2008-11-02) 
Different perl examples - some corners I rarely explore - (2010-07-18)P201 - Perl - Introduction 
Release numbers - (2004-08-23) 
Programming languages - a comparison - (2005-05-20) 
Central London Courses - Perl, PHP, Python, Tcl, MySQL - (2005-07-18) 
Learning to program in Perl or PHP - (2006-01-26) 
Twice is a co-incidence and three times is a pattern - (2006-02-07) 
Perl - multiprocess applications - (2006-02-13) 
Choosing the right language - (2006-03-01) 
Testing you Perl / PHP / MySQL / Tcl knowledge - (2006-04-19) 
Is Perl being replaced by PHP and Python? - (2006-08-27) 
The LAMP Cookbook - Linux, Apache, MySQL, PHP / Perl - (2006-11-13) 
Q - Should I use Perl or Python? - (2008-07-23) 
Perl v PHP, choosing the right language - (2008-08-14) 
Perl and Blackberries - (2008-10-23) 
Converting to Perl - the sort of programs you will write - (2009-03-08) 
What is Perl? - (2010-06-15) 
Are you learning Perl? Some more examples for you! - (2010-06-27)P050 - Perl - General 
The next generation of programmer - (2004-11-13) 
New in the shops - (2005-08-01) 
Glorious (?) 12th August - what a Pe(a)rl! - (2008-08-12) 
Keeping on an even keel - (2008-11-21) 
Where do I start when writing a program? - (2009-06-11) 
So what is this thing called Perl that I keep harping on about? - (2009-06-15) 
Lead characters on Perl variable names - (2009-08-24) 
Learning to program in ... - (2009-11-15) 
Perl Course FAQ - (2010-04-23) 
The Perl Survey - (2010-05-27) 
Perl course - is it tailored to Linux, or Microsoft Windows? - (2010-06-25) 
Should the public sector compete with businesses? and other deep questions - (2010-09-26) 
How many toilet rolls - hotel inventory and useage - (2010-12-18) 
How much has Perl (and other languages) changed? - (2011-06-10) 
DNA to Amino Acid - a sample Perl script - (2011-06-24) 
Perl - a quick reminder and revision. Test yourself! - (2011-08-26) 
Know Python or PHP? Want to learn Perl too? - (2012-07-31) 
Shell - Grep - Sed - Awk - Perl - Python - which to use when? - (2012-10-22) 
How well do you know Perl and / or Python? - (2012-11-04) 
Polishing the Perl courses - updated training - (2014-09-17) 
Perl - still a very effective language indeed for extracting and reporting - (2014-09-20)
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?