-2

Problem:

I am using a lot of CPAN modules and hard-coded perl functions in many different scripts (a lot of which is duplicated), and I want to make my code base DRY (don't repeat yourself) by extracting all of the common code (and maybe even by some refactoring), both own and cpan code into a common module and use that across my scripts, so that I need to change the code only one place when changes occur (they do).

So I want to ask you whether you are sitting on some functions you have implemented during your perl career that you would put permanently into such a common module so that when writing new scripts, you would only need to write code specific to the core functionality of the script, and use the common module for rest of the code.

AstroCB
  • 12,337
  • 20
  • 57
  • 73
Gogi
  • 1,695
  • 4
  • 23
  • 36
  • 2
    Refactoring code across multiple modules seems like a very massive undertaking. I don't doubt that there's duplication in the world of Perl modules, but what harm does it necessarily do? I'm not sure this question is a good fit for the site, as it's mostly an opinion-type question. – Jonah Bishop Feb 05 '13 at 14:41
  • If I did have a module or code that was any good then I would simply put it on CPAN. In the past I've had my own perl module that I've loaded into every project but often the problems they solve have been solved by a good CPAN module since! – Vorsprung Feb 05 '13 at 14:43

1 Answers1

4

Don't refactor CPAN Modules. Treat these as mystery boxes. If there's an issue of using multiple cpan modules that do more or less the same work, standardize on one.

I have a bunch of local Perl modules which I put in the Local namespace. For example, Local::WinAD to access and manipulate our active directory. This Local namespace will never be used by CPAN. It's stored in our version control system as a project, and can be checked out and installed on any system. You can use the use lib pragma.

If you do modules, do them right. Use @EXPORT_OK and not @EXPORT. (Or, even better, make them object oriented modules). Use POD documentation and do extensive unit testing via the Test::Simple and the Test::More modules.

Pretend you'll be submitting them to CPAN.

And, also search CPAN very carefully to make sure that you're not duplicating already done work. After all, you want to practice DRY which includes not redoing work already done for you by CPAN.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • Yes that's exactly what I have done. My local modules are exactly as if they were to be submitted to CPAN..Have used Test::More and done POD...And I am not duplicating anything. I have written a module for reading Maven pom.xml file, and other util modules. So the original purpose of the question was if any of you was sitting on some "killer" function or module that were so useful so I could include it my own module..... – Gogi Mar 14 '13 at 06:04