Healthier, Safer Code with Static Analysis

By Al Crowley, TCG Principal Engineer

Sometimes good people do bad things. Occasionally a person even commits an API key to a public GitHub repository. Once in a while, that person is you—but last month that person was me. The good news is that the leaked key was only for a development instance and it was quickly caught and invalidated. The project was just ramping up and we were still getting all the best practices configured.

The incident really bumped up the priority of doing things right and it got me looking at all the good static code analysis tools and services out there. There are plenty of command line tools and a number of SaaS offerings that are free for Open Source projects. Let’s start with some basics and move our way up…

Man holding a laptop over his head waving a flag that says, "Help!".

If your interests are focused on making your code “healthier,” a good place to start is a linter. My project uses JavaScript for the client and server, so my current linter is ESLint. ESLint is very configurable and they thoughtfully provide a number of preconfigured settings. The options go from the very utilitarian that will flag likely bugs, all the way down to the annoyingly pedantic details of code formatting. If you haven’t used a linter it’s not obvious what kinds of bugs a computer can find just by reading code. It’s usually things like:

if ( counter = 10 ) { … }

This is a totally valid syntax. In the super rare case that it’s actually what you want, it’s not a good idea. The code formatting rules are totally configurable so if you want a space before open function parameters, you can set that option. I highly recommend pairing this with an IDE configured to reformat your code automatically to the spec you setup in ESLint.

For warnings and metrics with a little more nuance, take a look at Code Climate. This is one of those ‘free for open source’ services so it won’t cost you anything if you have public repositories. Code Climate will grade your code, report on test coverage, and also give you an estimate of your technical debt in hours. It’s no better at estimating than any human, but it’s still fun to see. One really interesting feature is that Code Climate will comment on pull requests noting any new code issues or big chunks of code without test coverage. This can be really useful for teams just getting started with serious code review as it puts a neutral third party in the role of throwing the first stone.

Getting into the ‘safety’ side of code analysis you will find tools that scan your dependencies and imported libraries for known vulnerabilities. In my project, we are using Snyk. This is another free service for open source repositories. You can set up Snyk to run locally on-demand, as a service in the cloud that connects to your repository, or integrated with GitHub. This is going to be more useful for some projects than others. Something like Node.js uses so, so many public libraries that it’s impossible to manage upgrades without a tool. Your particular project may not have as much of a need.

Another security tool that would have caught my leaked API key is Git Guardian. Git Guardian will scan your commits for any string that matches an API key from the most popular services. Now granted, scanning repositories for keys is a bit like closing the barn door after the horse has bolted, but it does alert you right away. As long as you take action quickly, it should prevent any real issues unless someone is actively targeting you project.

Using all these tools won’t really speed up your project or fix every problem. It’s more of a ‘make the hard stuff easy’ kind of thing—but it’s mostly hard stuff that you didn’t have time to do before—unless your team is very disciplined. Code standards, dependency checking, and monitoring test coverage are hard to maintain when you are under time and budget pressure. My personal experience with code reviews on time-driven projects is that people really don’t want to flag code that works and request changes. Automated advice on how to write better code is most valuable when you are in the process of writing and testing the code for the first time. Putting tools in place that can do that should be a big win for your team.