Perl Coding Style and Maintenance

"TMTOWTDI" aka "Flexibility Incurs Responsibility"

The funny-looking acronym shown above is frequently sighted in Perl programming forums online, and stands for "There's More Than One Way To Do It". Perl gives programmers a lot of flexibility in terms of program design and coding style, but this comes at a price. Unfortunately, in some circles the language suffers from a reputation for "obfuscated" (unreadable) code. This not usually Perl's fault, but the fault of programmers who elect to write their programs in a manner that defies comprehension (even to themselves, in some cases).

When you write a program that's intended to serve as more than a one-off script that solves a temporary problem, try to follow some basic guidelines:

Include comments. Well-commented code informs the reader what each section does.
Use indentation. Indented code is easier to read, especially for tasks like nested loops and if statements.
Use subroutines and modules. Nobody wants to work with a script that consists of a single 5,000 line file with no subs.
Keep it simple. When given a choice between code that's straightforward or "clever", choose the easy route.
Separate content from design and application logic. This means avoiding the practice of embedding huge chunks of HTML in long programs. Try to store program logic, templates, and other application components in separate files. Follow web standards; use valid XML/HTML and CSS whenever possible.
Obey the first rule of optimization: don't. Unless you're trying to squeeze every CPU cycle possible out of your program, excessive optimization usually doesn't pay off in the long run. If raw speed is truly your your first concern, you might want to rethink your program's architecture first.

Any programming language can be used to write unmaintainable software. As you explore the wealth of freely available Perl scripts found on the web, you're bound to find some truly horrid examples of programming gone dreadfully wrong. Likewise, you'll see scripts that obviously reflect the time and effort the author put into usability considerations.

If you make you work available to others (a practice that is strongly encouraged), try to put yourself in the shoes of someone who's never seen your program before. Does it solve a particular problem in an efficient fashion? Does the code look like it's been through a bit grinder? Especially if the software you write have the potential to outlast your tenure at your current employer, put some effort into making sure future staff members will be able to easily maintain them. Writing "spaghetti code" is never a recommended tactic for improving job security, and only reduces your reputation among your peers.

The next chapter explores some basic guidelines for avoiding common security pitfalls.

Continue: Security Considerations

Table of Contents