@eliasp @ColinTheMathmo BTW #Perl has two well-known tools to encourage and enforce #programming style and best practices, respectively:
• #PerlTidy: https://perltidy.github.io/perltidy
• #PerlCritic: http://perlcritic.com

Your project or team can use their reasonable defaults or further configure them to reflect and maintain the consistent application of your preferences. They also integrate with editors/IDEs, source control management, and author #testing.

@dakkar @Perl `use v5.36;` or later will disable #Perl indirect object syntax.

And the https://MetaCPAN.org/pod/Perl::Critic::Policy::Objects::ProhibitIndirectSyntax policy will catch it.

You mandate things by adding #PerlCritic to your tests or pre-commit hooks, not by relying on your team’s individual vigilance

@ovid and other Perl :perl: mongers. What, if anything, do you use for code security?

I know that using taint gets you far, but SAST is mostly what I’m thinking (especially for legacy code without taint). Any tips?

Does Perl::Critic do a decent job, and is there a list of what its security policy and 3rd party plug-ins cover?

Other OS SAST I found are: https://github.com/htrgouvea/zarn and this grep-based one: https://github.com/wireghoul/graudit

Are they OK?

#SAST #Perl #AppSec #CodeSecurity #PerlCritic

@regehr @commodore @dev There is even a (low-severity, a/k/a “cruel”) #PerlCritic policy to discourage everything but $_, @_, $], and numbered #RegularExpression capture variables: https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProhibitPunctuationVars

https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProhibitMatchVars already protects you against the performance-sapping $`, $&, and $' match variables

And you can configure your own prohibited list with https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProhibitEvilVariables

#Perl #RegEx #RegExp #RegExes #RegExps

@rrwo Neat! TIL about the #Perl Sub::Util module and its `set_prototype` function: https://perldoc.perl.org/Sub::Util#set_prototype

Did you switch to that in https://github.com/robrwo/Hash-Util-Merge/commit/349e063981117193b1f95108490c74c4f3d8e419 just to remove #PerlCritic noise, or was there another reason?

@rbairwell @barubary Conway notes some problems with #Perl AUTOLOAD in “Perl Best Practices” (2005) and there is a severity 3 policy against it provided with #PerlCritic: https://metacpan.org/pod/Perl::Critic::Policy::ClassHierarchies::ProhibitAutoloading

Basic problems are: first AUTOLOAD wins in a class hierarchy; your AUTOLOAD has to handle/reject everything cleanly and is therefore an infinitely complex interface; AUTOLOAD gets called on object destruction if the class is missing an explicit DESTROY method

@rrwo In my experience, functions that return scalars are much more common than functions that return multiple values (lists), so all else being equal, return undef; is much more likely to be correct than return; in a function that returns a value.

I'm not a fan of the default #PerlCritic policies in general, but this one is just wrong.

@barubary @jens @RL_Dane @stoerdebegga Yes, covered `unless` and line length/formatting via #PerlCritic and #PerlTidy earlier:
• https://social.sdf.org/@mjgardner/109818309913140986
• https://social.sdf.org/@mjgardner/109818639137796370

@jens @RL_Dane @stoerdebegga One reason I choose #Perl is its expressivity without being too “large” of a language. (This last is why I still haven’t wrapped my head around #RakuLang—they threw so much into its core.)

I use #PerlCritic and #PerlTidy to set fairly strict defaults, but both have escape hatches for code islands that need to bend the rules for whatever reason (e.g. better modeling or critical-path performance, or sometimes fencing off legacy code to be brought up to spec later).

@RL_Dane Hah. Great question. The default policies are based on a book by Damian Conway (Perl Best Practices), many of which I disagree with.¹ (In fact, I would recommend avoiding any Conway modules in your dependency chain.) So I don't think the perlcritic defaults are sane, but alternatives are available (e.g. https://metacpan.org/pod/Perl::Critic::Community).

¹ From what I recall, a central point of the book is that the policies are not a "one size fits all" solution, but that you should consciously evaluate each recommendation and whatever the result, write it down (along with your rationale). That way you end up with a useful and consistent style guide for your org, even if you disagree with every single recommendation.

#perl #PerlCritic

@jens @RL_Dane @stoerdebegga #PerlTidy will help you with standardizing on line length and other formatting: https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy

And this core #PerlCritic policy will enforce it: https://metacpan.org/pod/Perl::Critic::Policy::CodeLayout::RequireTidyCode

@RL_Dane @jens @stoerdebegga #PerlCritic is not a module you ordinarily use. It is a command you run: https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic

Or a test you incorporate via something like https://metacpan.org/pod/Test::Perl::Critic or https://metacpan.org/pod/Test2::Tools::PerlCritic.

It would not make a lot of sense to require you to modify all your code to make sure it complies.

Default is to only report severe violations from all installed policies. The core policies are summarized here: https://metacpan.org/dist/Perl-Critic/view/lib/Perl/Critic/PolicySummary.pod

@RL_Dane @jens @stoerdebegga Opinions vary on how, but you should always check the return value of `open`. https://metacpan.org/pod/Perl::Critic::Policy::InputOutput::RequireCheckedOpen enforces that.

I like autodie: https://perldoc.perl.org/autodie

General consensus is that `unless` is confusing and postfix conditionals are too, except when used in flow control. https://metacpan.org/pod/Perl::Critic::Policy::ControlStructures::ProhibitUnlessBlocks and https://metacpan.org/pod/Perl::Critic::Policy::ControlStructures::ProhibitPostfixControls enforce that.

Since opinions vary, codify your projects’ standards in #PerlCritic’s configuration to settle arguments: https://metacpan.org/pod/Perl::Critic#CONFIGURATION

@rrwo @jens @stoerdebegga As for their continued use, see my earlier prescription of #PerlCritic: https://social.sdf.org/@mjgardner/109816886161869756

And use this core policy: https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProhibitPunctuationVars

@jens @RL_Dane @stoerdebegga (I also think every #CPAN distribution should include #perltidy and #perlcritic configs and author tests to encourage consistently-written contributions.)

@sjn @cb 99% of the “#Perl is line noise” complaints are because of unformatted #RegularExpressions. Every language worth anything eventually supports them, but only @Perl (and #awk, earlier) makes them first-class citizens. And with Perl you can format and comment them for readability: https://perldoc.perl.org/perlretut#Embedding-comments-and-modifiers-in-a-regular-expression

We format the rest of our code for humans. Why not #regexps?

#PerlCritic can warn against bad regexps: https://metacpan.org/search?size=200&q=module%3APerl%3A%3ACritic%3A%3APolicy%3A%3ARegularExpressions

#regex #regexes #programming #coding #SoftwareDevelopment

@smxi @ChristosArgyrop Of course, there’s a #PerlCritic policy to slap you on the wrist if you’re tempted to do such a rude thing as automatically export into a caller’s namespace: https://metacpan.org/pod/Perl::Critic::Policy::Modules::ProhibitAutomaticExportation

@ChristosArgyrop @Perl In answer to your question about #Perl symbolic references on the Twitter community (https://twitter.com/ChristosArgyrop/status/1612637569426280448), I still find them useful when you want to dynamically define things in the symbol table like functions/methods. Though Package::Stash provides a nice API for that so you don’t have to litter your code with `no strict 'refs'` and attendant #PerlCritic annotations. https://metacpan.org/pod/Package::Stash

@chrisjrob @snonux @Perl #PerlTidy and #PerlCritic also help with readable, maintainable, and consistent #Perl code. I like to joke that I don’t have a style, I have a perlcritic policy.

@living8bit FWIW it’s bad form to use $a and $b for your own #Perl variables unless they’re local to a block. They’re magic inside a sort block https://perldoc.perl.org/functions/sort

Here’s the relevant #PerlCritic policy: https://metacpan.org/pod/Perl::Critic::Policy::Variables::RequireLocalizedPunctuationVars