Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Thursday January 31, 2008
05:34 PM

Draft for list of good practices

[ #35546 ]

As I wrote in my previous journal entry, I am working on a list of good/best practices.

This is what I have so far, I have plenty of other things, but these might be too Perl specific, so I will save these for later.

So here is my current draft for a list of good practices.

  • Keep your subroutines small, for easier test and readability
  • Encapsulate complexity for faster understanding and readability. Blackboxes can be skipped at first glance to be revisited later.
  • Make your components distributable so they can easily be deployed else and everywhere
  • Keep your distributions as small as possible, so you only distribute logically related functionality and not unrelated components, resulting in unwanted side-effects upon deployment and avoid installing unnecessary stuff since later examination of installations can be misleading
  • Version everything, distributions, components, documentation etc.
  • Make your components environment agnostic, so they can move from development/test/staging/product/whereever without code changes
  • Make your components configurable so configuration changes can be made without code changes
  • Make your applications environment agnostic so they can be executed everywhere and not necessarily only on designated environments, if not possible make at least sure that the are testable
  • Test everything that could possibly break. Do not make assumptions about environment, encoding or execution.

I know you have something to add or at least a comment, so please let me know.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Test everything that ever has broken. If it breaks, write a test for it before fixing it.


    • Doh! how could I forget that, it is one of my favorite practices as you might can read I even forget to use this strategy.

      But when I have used it has proven magnificent.