Damian Conway highly recommends using the combo of 'xms' his Perl Best Practices Book ( https://www.oreilly.com/library/view/perl-best-practices/059... ).
The revised and considerably newer "Modern Perl Best Practices" video series on O'Reilly's learning platform is particularly good also ( https://www.oreilly.com/library/view/modern-perl-best/978149... ) - with lots of discussion of regexes.
Similar situation here. Perl is awsome and I'm still bitter that Python won. I mean significant whitespace - what great madness is this???
Anyway, yes, mod_perl ran the Web for about a decade in the early 2000s and I built and maintained huge websites which were all Perl on the back end.
BTW the book "Perl Best Practices" by Damian Conway [0] is the best general programming book I have ever read. Every software engineer should read it no matter what language they program in. So much good advice which applies to pretty much any significant software project. IMHO right up there with the "Mythical Man Month", though obviously much more low level.
[0] https://www.oreilly.com/library/view/perl-best-practices/059...
Myself I like coding in paragraphs very much, and giving the paragraphs one-liner headings (comments) definitely makes code for me more readable and easier to navigate.
I usually don't give a heading to a "paragraph" which is just one line, unless that line does something subtle. (Conway provides a definition of "subtle": if you need to think more than 10 seconds or consult the fine manual to figure out what the line does).
[1] https://www.oreilly.com/library/view/perl-best-practices/059...
The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.
My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.[4]
1: https://metacpan.org/pod/Modern::Perl
2: https://metacpan.org/pod/Task::Kensho
Yow, $30+ for the ebook! I wouldn't buy if just for that chapter… fortunately, the guidelines from the book have been codified as Perl::Critic, so If you don't mind missing out on the gently guiding text which accompanies each rule, you can browse the Perl::Critic::Policy::RegularExpressions[1] submodule docs.
[0]: http://shop.oreilly.com/product/9780596001735.do [1]: https://metacpan.org/pod/Perl::Critic::Policy::RegularExpres...
Perl 5 has a Tidy'ing tool[0], as well as a Lint[1] tool. Both are based on rules created from (originally) Best Practices [2]. These rules of course can be modified to taste, so you can set your own rules/filters before checking in your changes to a repo (or, whatever)
[0] https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tid...
Don't focus on the Perl language, just on their best practices for documentation. the guideline in terms of content are totally relevant for any language/developers and polished by practice.
Even if I chose to switch from Perl to python, I still miss Perl in terms of module distribution/testing/documentation.
Perl, and Perl community, I miss you, and I value what you learnt me :)
I advocate for people to be open minded and take good ideas without prejudice on their origins.
It's dear to me because it came along at a time when I needed short breaks from thesis writing.