Perl Debugged

by Peter Scott

Overview

The most vexing aspect a student will face while programming in Perl is debugging. The goal of Perl Debugged is to provide a way for the student to minimize debugging time, as well as minimizing the development and maintenance time needed for Perl programs. Geared towards students with some knowledge of Perl, this book guides students through the entire programming process, tackling the benefits, plights, and pitfalls of Perl programming. Beginning with a guided tour of the Perl documentation, the book progresses to debugging, testing, and performance issues, and also devotes a chapter to CGI programming in Perl. Throughout the book, the authors espouse defensible paradigms for improving the accuracy and performance of Perl code. In addition, Perl Debugged includes Scott and Wright's "Perls of Wisdom" which summarize key ideas from each of the chapters, and an appendix containing a comprehensive listing of Perl debugger commands. The engaging writing style will bring energy to the class!

Product Details

ISBN-13:	9780133891454
Publisher:	Pearson Education
Publication date:	04/30/2014
Sold by:	Barnes & Noble
Format:	eBook
Pages:	288
File size:	9 MB
Age Range:	18 Years

About the Author

Ed Wright is a Software Engineer at the Jet Propulsion Laboratory. He holds a Master of Science degree in Engineering Mechanics and Astronautics from the University of Wisconsin at Madison, a Master of Science in Physics from the University of Louisville and a Bachelor of Science in Mathematics from Auburn University. He currently leads the JPL Perl Users Group.

Peter J. Scott runs Pacific System Design Technologies, providing Perl training, application development, and enterprise systems analysis. He was a speaker on the 2002 Perl Whirl cruise and at YAPC::Canada, and he founded his local Perl Monger group. A software developer since 1981 and a Perl developer since 1992, he has also created programs for NASA¿s Jet Propulsion Laboratory. Scott graduated from Cambridge University, England, with a Master of Arts Degree in Computer Science and now lives in the Pacific Northwest. He is the lead author of Perl Debugged.

Read an Excerpt

Chapter 1: Introduction

1.1 Reality

Unfortunately for the programming world (and programmers), software development continues after a project is declared finished (an increasingly arbitrary-and often inaccuratelabel). Maintenance and debugging may consume more time than the original coding, particularly because the person responsible for a program's maintenance may not be one of the original programmers. This means we spend a lot of our time trying to deduce the specifics of some algorithm we find in the code: how it was done, why it was done, and why it doesn't work any more l

The odds of creating a bug-free program are rather long. Anything larger than the ubiquitous Hello World program is fair game for bugs. No recipe exists that, if followed, eliminates the possibility of bugs, but some practical rules have been developed:

1. Reduce the places where a bug may be introduced. This means incorporating modular design, encapsulation, and unit testing.

2. Identify the bug's pathology. Play detective: what shouldn't happen but does, or does happen but shouldn't?

3. Isolate the bug's locationwhere do things go south? (This is the reason for the invention of debuggers.)

4. Determine the conditions that cause the bug. What activates it? Why haven't you found it before?

5. Correct the bugand always retest altered code.

6. How did the bug get in there in the first place? If you made a typo and caught it 5 minutes later on a unit test, that's one thing. If the bug was caused by a logic error and survived to release, 1.2 Why Perl?

Chances are, if you use Perl you know why you picked it and don't need further proselytizing. But additional ammunition never hurts-if you have to defend Perl up your management chain, well, Perl doesn't have a megamultinational conglomerate to pour zillions of dollars into a marketing campaign 2 so it falls to users like us to sing its praises in practical ways.

Whenever we have a problem we need to solve with a program, the solution first shows up in our mind, in thought pictures and words, which most development methodologies then have us enunciate as an English (or whatever our native language is) description of an algorithm before ever translating it into code. If the algorithm description were complete and unambiguous, it could be executed by a computer if the computer could understand our phraseology.3 But no parser yet exists for free-form English algorithm descriptions, so we translate the description into some language a machine can comprehend.

Therein lies the rub: an ideal computer language imposes zero overhead on the programmer during implemention of the description. Such a thing doesn't exist, so we want the language that minimizes the overhead. This can vary from task to task-if you're writing a device driver, your best choice is quite likely to remain assembler. If you're writing a graphical user interface, at least part of the problem is probably best attacked with a WYSIWYG editor that creates a layout specification.

When writing a program, you're conscious of its overhead every time you create a requirement on code solely to satisfy the demands of the language but not the problem. For example, in writing C and C++ programs, a frequent example of this is how to allocate memory for dynamic data structures and where and when to give it up.

Perl imposes on the programmer the smallest overhead of any language we have used for the vast majority of problems we have had to solve. At the expense of little learning, we are able to create very short programs in an incredibly brief time to solve complex problems. Because the language overhead is small, changes in requirements don't force changes in large unrelated sections of the code since a much more natural mapping from the English description of the solution to the Perl version exists. And because the Perl expression of the solution is so succinct, a reader can encompass more of it at a glance.

In fact, in many respects, Perl resembles English in its ability to resolve ambiguities favorably, its intuitive and orthogonal interfaces, and even how it sounds when read out loud. Larry Wall, Perl's creator, often states how his background in linguistics led him to consciously draw such parallels. 5 Perl cognoscenti refer to this collective phenomenon as Perl's DWIM (Do What I Mean) behavior...

Table of Contents

Preface.
Perlness.
Who Are You?
What This Book Covers.
Getting Perl.
Typographical Conventions.
For Further Reference.
Perl Versions.
Acknowledgments.
1. Introduction.
2. The Zen of Perl Developing.
3. Antibugging.
4. Perl Pitfalls, Syntactical Sugaring.
5. Tracing Code.
6. Testing Perl Programs.
7. The Perl Debugger.
8. Syntax Errors.
9. Run-Time Exceptions.
10. Semantical Errors.
11. Resource Failure.
12. Perl as a Second Language.
13. Debugging CGI Programs.
Appendix A: Perl Debugger Commands.
Appendix B: Perls of Wisdom.
Index.

Preface

Perlness

In the world of languages, the country of Perl is the great melting pot which welcomes all cultures, religions, and beliefs. “Give me your tired, your poorly-supported programmers, your huddled masses yearning to be free of artificial limitations,” says Perl, and those who land on its shores find an environment where they are no longer hampered by a language designer's whimsical notions of elegant semantics and stifling syntactical purity.

Perl's universal availability and ease-of-use make it the most democratic programming language. Unlike many other languages, a relative beginner can write useful programs, whereas effective programmers in other languages normally need to spend a lot longer to learn syntax, operators, and functions. A Perl programmer may possess such expertise, or may be a newcomer who modified some example script to perform a new function.

But the newcomer has another problem: lack of debugging skills. Experience forces the canny to develop an innate knack for debugging due to years of accumulated pain. We want to minimize that pain, because we have suffered it. Perl's ease of use allows programmers with little knowledge to create usable, if buggy, code. The amount of time it takes to debug a Perl program can vary dramatically from person to person. Our goal is to help you minimize the development, debugging, and maintenance time you need for your own Perl programs.

Do not take the title of this book to meanwe are debugging Perl itself in these pages. What few bugs exist in the Perl interpreter are a matter of minute exotica (or exotic minutiae), rapidly squashed by the fine volunteer crew supporting Perl. A more accurate title would have been Debugging Your Perl Programs, but that is far too pedestrian and loses the “unplugged” pun.

We wrote this book because we wanted you to see the development process at work. Most books on programming contain carefully crafted examples honed through sweaty practice to work perfectly and stand as mute testimonial to the elegant style of the author. They don't show you the ugly, irritating process it took to get the examples into shape; yet those examples did not in fact spring into existence fully formed from the forehead of their creator. Because you will experience this same process when developing your programs, we want to guide you through it and describe various ways around the embarrassment, humiliation, and surprising pitfalls that stand between you and Great Programming.

Within this book, we describe the most common and annoying mistakes a new Perl programmer might make, then detail the procedures to identify and correct those bugs and any others. You should have some knowledge of Perl; several fine tutorials exist to free us from the onerous responsibility of explaining scalars and arrays and hashes and the like. This Preface includes a few references to some of the most useful of these tutorials.

We will not attempt to define or describe a proper programming “style.” Style is as unique as an individual–but a few general rules create a common reference so that we can easily read each others' programs.

Neither is this a “how to program” book. Although we will probe into the mechanics and underpinnings of the general principle of programming at times, it is not our intention to inculcate a complete newcomer with the mindset of the programmer's discipline.

Who Are You?

If you've been programming in Perl anywhere from a week to a year and you want to speed up your development cycle, this book is for you. We'll also address some issues related to developing in a team. This book is intended to assist those who have started learning Perl by providing practical advice on development practices.

 

What This Book Covers

Here's what you'll find in the rest of this book:

• Chapter 1: Introduction and a guided tour of the Perl documentation
• Chapter 2: Developing the right mindset for programming and developing effectively
• Chapter 3: “Gotchas” in Perl: working your way around some of the tricky things to understand or get right in Perl programming
• Chapter 4: Antibugging: How to code defensively
• Chapter 5: How to instrument your code
• Chapter 6: How to test your Perl programs
• Chapter 7: A tour of the perl debugger: our guide to using this built-in tool
• Chapter 8: Types of syntax error and how to track down their causes
• Chapter 9: Run-time errors
• Chapter 10: Semantical errors: when your program appears to work but doesn't do the right thing
• Chapter 11: How to improve the performance of a resource-hungry (memory, CPU cycles, and so on) program
• Chapter 12: Tips and pitfalls for people coming to Perl from other languages
• Chapter 13: Common Gateway Interface (CGI) programming: special tips for debugging this type of Perl program
• Chapter 14: Conclusion
• Appendix A: Reference for the perl debugger commands
• Appendix B: List of our “Perls of Wisdom”

We will spend a lot of time going through examples of problems and how you might debug them.

 

Getting Perl

While this isn't a book about how to install or build perl, we owe you at least

rudimentary instructions on how to get a perl of your own.

• For Windows machines, get the free ActivePerl distribution:

...

Editorial Reviews

"This book was a joy to read. It covered all sorts of techniques for debugging, including 'defensive' paradigms that will eliminate bugs in the first place. As coach of the USA Programming Team, I find the most difficult thing to teach is debugging. This is the first text I've even heard of that attacks the problem. It does a fine job. Please encourage these guys to write more."
–Rob Kolstad

Fatbrain

The Barnes & Noble Review
As Perl Debugged coauthors Peter Scott and Ed Wright observe, Perl is the most democratic of programming languages. "Those who land on its shores find an environment where they are no longer hampered by a language designer's whimsical notions of elegant semantics and stifling syntactical purity." That means Perl programmers can write useful code surprisingly quickly. Unfortunately, that code is often quite fragile, because its authors don't thoroughly understand its implications.

When it comes time to debug, these Perl developers are at a double disadvantage: Since they don't have experience to guide their intuition, they must embark on a painful trial-and-error process to figure out what went wrong, and how to fix it. Even experienced Perl developers vary widely in their efficiency as debuggers: Some handle problems with aplomb, while others of equal intelligence continually struggle.

In Perl Debugged, Scott and Wright set out to streamline the debugging process, bringing together the Perl developers the community's best wisdom on troubleshooting Perl code -- and avoiding problems in the first place. If you depend on Perl (whether as web glue or for more traditional applications), this book will save you an immense amount of frustration.

The authors begin by summarizing the "generic" (but still immensely important) methods for building more effective code -- for example, reducing the places where a bug may be introduced, by incorporating modular design, encapsulation, and unit testing. Next, you journey inside -- inside your own mind, that is. As Wright and Scott write, "the left-brain formal minutiae of creating smart code; and the right-brain, soft, touchy-feely stuff that goes on in your head. Most programmers would rather ignore the touch feely stuff because it's just Not Their Thing. However, we've found that it's more important than the rational left-brain information, because it affects everything you do."

Some of this is about the habits developers choose to learn -- precision, neatness, consistency, clarity, and a willingness to experiment ("Don't spend ages trying to second-guess the machine: find out. If you're not eager to find out what would happen in some odd situation cooked up by your fertile mind, then cultivate the attitude of curiosity, because people who have it will move along the learning curve much faster than those who don't.")

Next, it's on to what the authors call "antibugging": how to ask the right questions about what went wrong; how to document your code effectively with as little effort as possible ("we hate it too"), and exactly whom to steal good code from (they actually list 35 great Perl coders whose work is widely accessible). You'll also find specific tips on reducing complexity (first thing we do, we kill all the temporary variables).

You'll find a detailed chapter on the Perl traps that are easy to fall into if you don't know all the nooks and crannies: stuff like precedence problems, odd behavior related to autovivification and function prototypes, and so forth.

There's a full chapter on tracing code, and another on testing it (many developers don't realize how much code Perl comes with that can streamline regression testing for them). You'll also find detailed coverage of Perl's debugger -- ordinary an arcane topic, but one that this book makes far more accessible.

Scott and Wright show you how to root out run-time exceptions and syntax errors (did you know the average programmer makes one error for every 7-10 lines of code, and nearly one-fifth of those are simple typos)? There's an extensive review of the most common Perl semantical errors, and a guide to handling resource constraints (the authors remind us to optimize for people first, and only afterwards for cheap memory, processing power, or disk space).

You'll find guidance specifically targeted at developers coming to Perl from C, C++, FORTRAN, Java, or Unix shells; as well as a full chapter on CGI debugging (including how to tell if your problem is Perl related or CGI related).

In addition to being exceptionally useful, Perl Debugged is a pleasure to read. Imagine ever saying this about a debugging book: We read it end to end, and it was over too soon -- and yes, we do have a life. (Bill Camarda)

Bill Camarda is a consultant and writer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

bn.com

This guide for novice to intermediate software developers focuses on the process of Perl programming and identifying and correcting mistakes. Beginning with an overview of the Perl documentation, the text then covers debugging, testing, and performance issues. An entire chapter is devoted to CGI programming in Perl. A comprehensive reference of Perl debugger commands also is included. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Booknews