Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

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!

There are no stupid questions, but there are a lot of inquisitive idiots.

In reply to 20 tips to avoid pitfalls while Programming Perl by greengaroo

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2024-04-19 23:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found