Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

jonasbn
  jonasbnNO@SPAMcpan.org
http://usr.bin.dk/~jonasbn/
AOL IM: BJonasN (Add Buddy, Send Message)

Freelance 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
06: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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Test everything that ever has broken. If it breaks, write a test for it before fixing it.
    --

    --
    xoa

    • 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.