Although I’ve been programming in Perl for over 25 years, it wasn’t until recently that I’ve had a boost in productivity as great as the one I experienced over the last year. What happened?
Stepping out from a more management oriented role at my former
employer, they needed a technical leader for a legacy Perl web
application migration to the cloud. Somehow I let on that I had some
Perl and AWS experience and so I was tabbed as the technical lead.
The project involved some heavy lifting of years of crufty Perl code
from an on-prem, dedicated Apache server environment to a
containerized AWS environment. Aside from the challenges of trying to
get legacy Perl code running in a Docker container the team had to
mitigate findings from the company’s security scans. This included
perlcritic findings as well as findings based on other tools that
look for potential security issues.
So, the first hurdle was whittling down the
perlcritic findings and
making sure we weren’t introducing new findings.
perlcriticto the Build
I’m a big fan of
autotools so naturally our build was
based on GNU
allowed for a repeatable, standards based, reliable and
extensible build system that worked locally using
worked in our CI/CD pipeline to deploy Docker images for AWS Fargate.
To make sure that we maintained a baseline of low severity findings
perlcritic, I added a step in our
Makefile that ran
perlcritic and errored out if any severity level exceeded 2. This
prevented any code from going into the repository that would trigger
security concerns since all pushes to the repository were scanned.
My editor of choice has always been Emacs…let the editor wars begin!
I had already added
perltidy as an extension to Emacs so that
perltidy would be run before any save. Our team standardized on a
perltidy settings and added the
.perltidyrc file to the
project along with the
.perlcriticrc that configures
Most editors today have language specific syntax highlighting and syntax checking built-in. Flycheck is an Emac’s plugin for syntax checking. Flycheck extensions are available for almost any language and even for things like markdown, JSON and SQL.
Syntax checking as you work in your scripts is
another way to move the process of validating your code further
upstream, but what really supercharged my development efforts was
perlcritic checking to Emacs. The combination of Flycheck’s
perlcritic and Perl syntax checking has
helped me develop faster with less errors.
Perl Best Practices isn’t just code for “standarization”, although having some standards makes maintenance a heckuva lot easier. No, PBP can highlight potential issues in your code and prevent you from having to debug gnarly problems.
Unfortunately, it’s also a nag.
Visiting an old legacy file that someone wrote back in 2012 (before you and they were woke to PBP) is an eye opening experience. When Flycheck gives up after 1527 issues found you start to question whether you really want to edit that code!
Even code that has relatively few findings presents them with electric hilighting that eventually rattles your nerves. It also becomes a bit of an obsession to clean up old code and get down to 0 findings!
In the end tough, the result is better code. Other programmers can read and understand it and the quality will get incrementally better.
Generally speaking then, to supercharge your development efforts move code quality enforcement as far upstream as possible, starting with your editor.