20 tips to avoid pitfalls while Programming Perl

[greengaroo]

Hello Monks!

This post is a follow-up on my previous meditation entitled: 20 most important Perl Best Practices. Your replies in that thread made me realize that my list was wrong and I was not really achieving my goal. I meditated on it and I came up with new ideas.

Let me re-state the premise of my endeavour, my mission if you will: To create a list of 20 tips for Perl developers to avoid common pitfalls.

I came up with 15 so far. I would appreciate if you take a look at my new list and comment. Maybe 15 is enough, maybe 20 is too much. We'll see.

Here's the list:

1) Keep in mind software is a mean to an end (most of the time), it's not the product. The software must comply with the requirements and not the other way around. However, sometimes, requirements are questionable. So stick to the priorities AKA "most important features".

2) Keep in mind you will not be the last developper to look at your code. Make sure your successor will not hate you!

3) Keep it DRY! Don't Repeat Yourself! This leads to mistakes and bugs. Learn Object-Oriented programming if you have to!

4) Don't reinvent the wheel! Search on CPAN.org, Google, and ask your colleages about utility functions you may need. If you think about something, probably others thought about it before you.

5) Be consistent with the input and output of functions or methods, be consistent with the code style, with your naming convention, etc. In other words, be consistent.

6) Raise a flag, when creating if-elsif blocks without an else. Double-check that you don't need an else. In doubts put one that would provide an error message.

7) Be mindful when using internal variables such as $_, @_, $1, $2, etc. These variables could possibly lead to strange problems.

8) Don't pass big structures directly as an argument to a subroutine or method, use references instead. You never know how big your structure could become and it would use a lot of memory.

9) Leave a comment when doing something that is not obvious to understand.

10) If you choose to create unit test scripts to cover your code, maintain it!

11) Very long one-liners could be hard to read. Keep it short or avoid it for readability purpose.

12) Take space! It's free! You don't have to pack your code in small blocks, let it breathe, so others can appreciate reading it!

13) You are not alone! Do code reviews on your code and participate in others. This is an easy way for others to give you hints on what you are doing wrong as well as a good opportunity to see how other people are doing it.

14) Don't get stuck on a bug for too long! If you can't figure it out, try to follow these steps:

• Add use strict and/or use warnings;
• Learn how to decipher obscure error message and fix syntax issues;
• Create a unit test script to cover this part, maybe you will find the problem this way;
• Google your problem;
• Talk to a colleague about your problem;
• Ask a colleague to look at your problem;
• Sleep on it, take a break, a coffee, a walk, then come back to it!

Most likely, you will find your solution within a few of these steps. If not $solved then goto rule 15;

15) Visit PerlMonks.org daily!

Thank you all!

[Athanasius]

++greengaroo, your list contains good advice. I would like to add some of my own. But, first, I do have a few quibbles:

6) Raise a flag, when creating if-elsif blocks without an else. Double-check that you don’t need an else. In doubts put one that would provide an error message.

This should stated more generally:

Be mindful of corner cases. Remember Murphy’s Law! For example, when creating if-elsif blocks without a closing else block, ...

8) Don’t pass big structures directly as an argument to a subroutine or method, use references instead. You never know how big your structure could become and it would use a lot of memory.

This is true in C, but not in Perl, where subroutine arguments are passed by reference, not by value. See perlsub:

The array @_ is a local array, but its elements are aliases for the actual scalar parameters. In particular, if an element $_[0] is updated, the corresponding argument is updated...

Of course, once the argument has been passed in, it is common practice to assign it to a local variable, and this assignment does make a copy. So point 8) is still good advice, but needs to be re-stated (and generalized). For example:

Don’t make an unnecessary copy of a large structure when a reference will serve instead.

14) follow these [debugging] steps:

This tip should definitely include a reference to Basic debugging checklist by toolic.

Now to my proposed additions:

16) Observe the Principle of Least Privilege. Don’t use a global variable where a lexical variable will do. Don’t declare your variables until they are needed. Use accessor methods on objects. Use blocks to minimize the scope of local, no strict 'refs', etc.

17) Avoid premature optimization. Remember,

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. — Donald Knuth

In fact, the Wikipedia article on program optimization says it all:

A better approach is therefore to design first, code from the design and then profile/benchmark the resulting code to see which parts should be optimized. A simple and elegant design is often easier to optimize at this stage, and profiling may reveal unexpected performance problems that would not have been addressed by premature optimization.

18) Study Chapter 21, “Common Practices,” of the Camel Book.

Hope that helps,

[Anonymous Monk]

Principle of least scope or maybe lifespan would have been better ... what you describe is not the meaning of the term least privilege, which does have a very definite meaning.

[philiprbrenan]

May I propose: "the length of variable names should be proportional to their life expectancy"?

[philiprbrenan]

Perhaps also: "Good code: beautiful yet functional"

[philiprbrenan]

And also: "Life is short, code should be so too."

[karlgoethebier]

My 2˘:

3): Sometimes it's easier and faster to repeat yourself. Yes, yes.

7): Sure, they can be abused. But what Perl would be without them?

9): But what is obvious - or not? And remember good old perlpod.

11): If a one-liner is too long something went wrong ;-)

14): This is unrealistic.

16): Always use Perltidy

17): Use some versioning system (RCS, Git, Subversion...).

18): Use macros/scripts to generate the skeletons for your scripts/modules/classes.

19): Remember the egg of Columbus.

Regards, Karl

[sundialsvc4]

This is a well-considered list.   Thanks for sharing what you have so far.

[stonecolddevin]

use Moose;