@Pyrrhlin I like to see the test first when reading from left to right.
Per #perlcritic I reserve postfix controls for program flow control functions like return, last, next, etc. https://metacpan.org/pod/Perl::Critic::Policy::ControlStructures::ProhibitPostfixControls
@tripleo #Perl’s “sharp edges” are mainly early syntax and features that later experience with large and networked #programming found dangerous, but are preserved for backward (and we do mean “backward”) compatibility.
See the details of the `strict` and `warnings` pragmas, and successively missing items in `feature` bundles:
• https://perldoc.perl.org/strict
• https://perldoc.perl.org/warnings
• https://perldoc.perl.org/feature#FEATURE-BUNDLES
And the summary of policies included in #PerlCritic: https://MetaCPAN.org/pod/Perl::Critic::PolicySummary
@aimaz Yes, and many of the #Perl recommendations by #CERT (https://wiki.sei.cmu.edu/confluence/x/wlxMBQ) have corresponding #PerlCritic policies: https://metacpan.org/dist/Perl-Critic/view/lib/Perl/Critic/PolicySummary.pod
Perl app and module #developers can easily incorporate a perlcritic test into their test suite to catch #security and other problems: https://metacpan.org/pod/Test::Perl::Critic
#InfoSec #CyberSecurity #programming #coding #SoftwareEngineering #SoftwareSecurity
@Perl If you were at last year’s #Perl and Raku Conference in Toronto, you might have heard @davorg's talk on #GitHub Actions. He's recently released a set of reusable workflows for you to try in your projects: https://perlhacks.com/2024/01/github-actions-for-perl-development/
Right now you can run your tests on a variety of operating systems, check test coverage, and run #PerlCritic across your code. He's also working on #CPAN release and #DistZilla testing workflows.
@nobodyinperson Bliss to write but not to read as tortuous double-negatives pile up with maintenance. The ProhibitUnlessBlocks #PerlCritic policy exists for a reason: https://metacpan.org/pod/Perl::Critic::Policy::ControlStructures::ProhibitUnlessBlocks
This applies to both `unless` and `until`. Congratulations if you've used them in the past: you contributed to #Perl's reputation as a write-only language in the eyes of the person who had to revise your code to deal with more complicated conditions.
@lemorin This also means you can disable the Modules::RequireNoMatchVarsWithUseEnglish #PerlCritic policy (https://metacpan.org/pod/Perl::Critic::Policy::Modules::RequireNoMatchVarsWithUseEnglish) if you can be sure you’re running on #Perl v5.20 or later!
@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?
@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
@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?
@ovid @polettix It must have bit haukex and perlancar enough to make a #PerlCritic policy: https://metacpan.org/pod/Perl::Critic::PolicyBundle::PERLANCAR::Variables::ProhibitFatCommaInDeclaration
@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.
@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.
@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
