Programmer Musings

Review of Perl Best Practices

Perl Best Practices
Damian Conway
O'Reilly, 2005

This book is hard to summarize. There is much good advice in this book. Unfortunately, there's also some advice that I found questionable. Conway covers some of important Perl and general programming best practices, including consistent formatting, use of strict and warnings, and the use of version control software. Unlike my standard book on best practices, Code Complete, Conway does not provide much independent support for his assertions. On the obvious best practices (meaning those you agree with), this is not a big issue. However, I did find it difficult to accept suggestions to change coding practices I've developed over almost two decades without any supporting evidence.

Without that evidence, I found some of Conway's arguments to be less than convincing. For example at the beginning of Chapter 2, he states that consistent layout is important, but which particular layout style you use does not matter at all. So far I agree with him completely. Then, he goes on to spend over 25 pages describing his preferred layout style, listing each point as a best practice and spending time justifying his choices. If the particular layout style does not matter, shouldn't we have had one best practice, use a consistent layout style instead of 22 individual layout suggestions elevated to best practice status?

I was also interested to find that more than 10 of the recommended modules were written by Damian Conway. Some of these appear to have been updated on CPAN relatively recently. That makes me wonder how they have had time to become best practice.

Some of his rules appeared to be somewhat contradictory. For instance, we shouldn't use unless because it is not as familiar to many programmers and it is harder to understand complicated boolean expressions in an unless. But, we should use redo to restart a for loop without incrementing the variable when we need more complex flow control. And we should prefer \A and \z in regular expressions, because

They're likely to be unfamiliar to the readers of your code, in which case those readers will have to look them up, rather than blithely misunderstanding them.

Although these suggestions may be good practice and may actually help in writing maintainable code, I find it impossible to detect an underlying philosophy driving this particular set of suggestions.

If you've read this far, you probably have gotten the impression that I hated this book. That is very far from the truth. Damian Conway is a prolific Perl programmer with loads of experience. Much of his advice parallels my own philosophy in writing code, in Perl and in other languages. As I was reading the book, I installed several of his suggested modules and have even modified a few of my Perl programming practices based on his arguments. However, I would be uncomfortable suggesting that a new Perl programmer use this book as the reference on how to program in Perl.

In general, I believe that my biggest problem stems from the expectations I had from the title. If it had been called Damian Conway's Recommended Practices for Perl, I would have been a bit more forgiving. However, by setting itself up as the book on Perl best practices, I feel that the practices in the book need to be more than Conway's recommendations. Supporting evidence or studies would have made it easier to swallow his suggestions where they disagreed with my own practice. Less inconsistency between different rules would have made me more comfortable that he has an underlying strategy instead of listing the part of the language that he, personally, likes. Better disclosure about the modules he wrote and their age, would have made the book feel less like an infomercial in spots.

All in all, I think I would recommend this book to more senior Perl programmers or senior programmers coming to Perl. I would be a little leary of recommending it to novice Perl programmers without some strong suggestions that they take this as one person's view. The really frustrating thing is that I really wanted a book to be the standard I could use to counteract the myth of write-only Perl. Unfortunately, I don't think this book will do that.

All that being said, there is a large amount of good advice in this book. As long as you take the advice with an appropriately-sized grain of salt, this book could improve your Perl code.

Review of Perl Testing: A Developer's Notebook

Perl Testing: A Developer's Notebook
Ian Langworth and chromatic
O'Reilly, 2005

This is the first book I have read from the new O'Reilly Developer's Notebook series. Although the style of these books probably won't work for every topic, it works particularly well for a book on testing. Each chapter is organized as a set of labs. These labs walk through some portion of the topic with the goal of developing practical skills.

Each lab revolves around a task. They don't delve into theory, they focus on describing how you perform the task. Unlike O'Reilly's Cookbook series, this is a directed set of tasks. Much like labs in a class, the labs in this book start with basic testing skills and work to build more advanced testing skills. The goal of this set of labs is to help you become proficient in the skills needed for doing quality unit testing of Perl code.

I have been doing testing with Perl for some years now, so the first few labs were review. But, the labs swiftly escalated to more advanced topics that I was either light on or had not explored at all. In addition to labs about Test::Simple, Test::More, and Test::Harness, the book covers:

• testing the POD documentation in your modules
• coverage testing
• testing exceptions generated by code
• testing warning generated by code
• building testing libraries to simplify testing
• mocking objects
• overriding system calls
• testing databases
• testing websites

and many more topics related to testing. This little book is packed with practical information and labs that help you improve the skills you need to build quality testing for your Perl code.

I really don't expect this book to become a well-worn reference book that stays near my desk at all times. However, I don't expect to let it get far away. Since few of us need to use all of our testing skills on every project, some skills become rusty over time. Anytime I find some of my testing skills have gotten rusty, I expect to grab this book and run through the appropriate labs to sharpen the skills I need.

If you want to know why you should be unit testing your Perl code, there are many books out there that will explain. If you are looking for an explanation of Test Driven Development, this is not the book to read. Once you have decided that testing is important to you and your projects, this is the book you need. I would not say that there are no other resources for learning this material, but this may be the fastest way to build the appropriate skills that I've seen.

It also helps that the authors have a very relaxed style that helps you feel more like they are working along side you than lecturing at you. The titles of the sections are very casual (How do I do that?, What just happened?, etc.) This makes it easy to read the next part and get back to working on the meat of the lab.

I would recommend this book to anyone writing Perl code. We all need to be doing testing to improve our code and our designs. The key difference between good testing and bad testing is the skills to make every test count. This book teaches those skills.

Review of Perl for Web Site Management

Perl for Web Site Management
John Callender
O'Reilly, 2002

This book may be one of the best books I've ever seen for getting Perl used in a place where it is sorely needed.

Many people developing web-based applications are not programmers. They learned to use some HTML authoring tool and progressed from there. Many of them never quite get the idea of automating the grunt work of their jobs. This book tries to introduce these people to Perl as a labor-saving device.

If you are doing any form of web site maintenance, this book is worth a read. If you are a programmer working on web sites, you are probably doing most of what this book teaches. But, if your background is not in programming, this book will probably increase your productivity dramatically.

Review of Mastering Regular Expressions

Mastering Regular Expressions
Jeffery E. F. Friedl
O'Reilly, 1997

If you use regular expressions on a regular basis, or if you've used them a little but want to get better, this is a book you need. I had been working with regular expressions for over ten years when I first read this book. I was used to helping other people debug their regular expressions and thought I knew them very well. This book improved my regular expressions tremendously.

The book covers multiple regular expression implementations, including AWK, grep, Tcl, GNU Emacs and Perl 5 regular expressions. Friedl does a good job of covering basic regular expression concepts before going on to more advanced topics. Some of these include different types of regexp engines and their effects on the expressions you write, and greediness. He covers some regexp gotchas including regular expressions that may never terminate.

Throughout the book are a number of useful techniques that will improve your daily use of regular expressions.

Mastering Regular Expressions is highly recommended.

Regular Expression Maintainablity

perl.com: Maintaining Regular Expressions [Jan. 16, 2004]

Aaron Mackey does a wonderful job of suggesting more maintainable regular expression idioms. His use of (?{}) to assign the results of capturing parenthesis inline was particularly interesting to me. I may have seen it before, but this is the first time it made sense.

The article goes into some serious magic later including deferred execution of the (?{}) blocks and Regexp::Fields.

Unit tests that should fail

I was doing a little research on the Java JUnit test framework and ran across the article The Third State of your Binary JUnit Tests.

The author points out that in many test sets there are ignored tests as well as the passing and failing tests. As the author says, you may want to ignore tests that show bugs that you can't fix at this time. He makes a pretty good case for this concept.

The Perl Test::More framework takes a more flexible approach. In this framework you can also have skipped tests and todo tests in addition to tests that actually need to pass. These two different types of tests have very different meanings.

Skipped tests are tests that should not be run for some reason. Many times tests will be skipped that don't apply to a particular platform, or rely on an optional module for functionality. This allows the tests to be run if the conditions are right, but skipped if they would just generate spurious test failures.

Todo tests have a very different meaning. These tests describe the way functionaly should work, even if it doesn't at this time. The test is still executed. But, if the test fails, it is not treated as a failure. More interestingly, if a todo test passes, it is reported as a failure because the test was not expected to pass. This allows bugs and unfinished features to be tracked in the test suite with a reminder to update the tests when they are completed.

Unlike the idea in the referenced article, these two separate mechanisms don't ignore tests that cannot or should not pass. Instead, we can document two different types of non-passing tests and still monitor them for changes.

Perl as a "dinosaur"?

Someone asked a question about updating SVG dynamically from a server on the SVG Developers list this morning. One of the (many) responses pointed to an article on SVG server-side.

As usual, I went to check it out to see if it might hold some tidbits I could use. Or maybe, it could be a resource I might recommend. While scanning the article, I found this little quote

Perl is the dinosaur among web scripting languages, its market share (when it comes to server side web scripting) getting smaller...

They go on to point out that in Perl you have to manually set the header.

I find it amusing that people that want to show Perl in a bad light ignore modules like CGI.pm that help to give Perl most of the support you need for web scripting. CGI.pm has been out there for a long, long time. It's been part of the standard distribution since version 5.004.

To give the authors credit, they do mention the SVG.pm Perl module for generating SVG using Perl objects.