in reply to Is it a good idea to create custom modules?

In short, this is a really good idea ... if done correctly. If done poorly, it will destroy your world in a bad way.

My first statement is to not use @EXPORT and instead use @EXPORT_OK. Then, do a use Shortcuts qw(debug);. That allows a reader of your code to know exactly where debug() is coming from. This is part-and-parcel of self-documenting code.

This is one of the bigger discussions in programming theory. I'm in the process of reading Code Complete (which I highly reccomend) and it discusses this very topic in great length throughout the book (of which I'm on chapter 8).

Basically, it all depends on a few factors:

  1. Are you documenting this? This is the biggest one.
  2. Are you using this in a large percentage of places?
  3. Are you using this as a repository of common functions? Are they documented?
  4. Do you have any globals? If you do, rip them out. Globals in a stand-alone script are arguably justifiable, if absolutely horrid style. If you start using globals across module lines, any reader of your code will rewrite it in disgust.
  5. Along the lines of #4, do NOT break the module's encapsulation. Ever. Not even once. Not even jokingly. If you're going through the trouble to create a module to store functionality, use all of its features and make it a black box. That way, if you want to change something across all your scripts (which is what this would allow you to do), you can do so and know that every script will still run, so long as you don't break the contract between the module and the scripts.

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!