Re^2: PM vs PL

Yeah...I'm guilty of learning what I needed to learn to make things work, then not learning much else until I needed to make something else work. So having learnt to require *.pl files, I have just kept doing it.

Maybe I could claim I write fashionably retro code :P

Comment on Re^2: PM vs PL Download Code

Replies are listed 'Best First'.
Re^3: PM vs PL by eyepopslikeamosquito (Archbishop) on Nov 20, 2020 at 23:41 UTC
My first reaction on seeing `require` of a `.pl` file is that it is very old code. I would call it a code smell. I prefer to put as much code as possible in CPAN-style modules (`.pm` files), with associated unit tests (`.t` files) for each module. The ideal is for commands (`.pl` files) to be very very short, with almost all automated testing heavy lifting delegated to the module level, leveraging the excellent Perl CPAN module testing tools, such as the `prove` command. An extreme example of this approach is Perl::Tidy whose `perltidy` command is essentially just: `use Perl::Tidy; my $arg_string = undef; exit Perl::Tidy::perltidy( argv => $arg_string );` [download]	[reply] [d/l] [select]
Re^4: PM vs PL by Bod (Parson) on Nov 21, 2020 at 00:12 UTC
I prefer to put as much code as possible in CPAN-style modules (.pm files), with associated unit tests (.t files) for each module. Oh! That's what those *.t files are for... Now I am reading Test::Tutorial which is something else I didn't know existed.	[reply]