Credit: https://nasa.gov

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?

Projects Present Opportunities for Change

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.

Adding perlcritic to the Build

I’m a big fan of make and autotools so naturally our build was based on GNU autotools. This allowed for a repeatable, standards based, reliable and extensible build system that worked locally using docker-compose and 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 from 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.

Moving the Checks Further Upstream

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 set of perltidy settings and added the .perltidyrc file to the project along with the .perlcriticrc that configures perlcritic reporting.

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 adding perlcritic checking to Emacs. The combination of Flycheck’s support for perltidy, 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.