As developers, we’re always looking for ways to make sure that the code that we deliver to our customers is as error-free as possible. There are lots of ways that we can do this but most developers tend to rely on manual and automated testing.
Manual testing is flawed because we constantly have to redo our tests manually. Automated Tests are more efficient because it’s automatically done which can save us huge amounts of time. The downside is that they require a non-trivial amount of effort from the developers to create them off.
There’s a third option that’s generally overlooked as a way to improve our code’s quality requiring just a little extra effort on our part. That’s using static code analysis. In this article, we’ll discuss what static code analysis is and why we should be using it on every commit.
What is Static Code Analysis?
Static code analysis is a process by which we analyze our source code without actually executing any of the code. This is in contrast to dynamic code analysis where we run the code either through manual or automatic means.
Static code analysis is a term applied to an analysis of code using automated tools. We can do the same types of analysis manually in processes like code reviews. Manual code reviews are good for questions like “Does this change do what we want” but it’s time-consuming and error-prone for determining if the code is formatted correctly and returning the correct types.
Why Should We Do Static Code Analysis?
There are lots of reasons we should be using static code analysis but we’re going to be talking about the two reasons that we feel give us the most return on investment.
The first is bug reduction. By using static analysis tools we can inspect our code to see where we’ve created syntax errors, we’re calling functions or referencing variables that don’t exist and returning one type when we expected another.
The second is rule validation. Using static analysis tools we can make sure our code adheres to a set of rules that we’ve defined so we don’t have five developers writing code in 5 or more different ways. Think of the arguments that have happened over tabs vs spaces and then how many spaces!
In this series, we’ll discuss a couple of tools that will perform this type of static code analysis so make sure you subscribe to be notified when a new video/article comes out.
Who Should Do Static Code Analysis?
Every organization of any size should be doing static code analysis. Sometimes it takes a little while to work it into a product cycle’s development but it can be a huge boon to productivity and reduction of bugs and technical dept. We include static code analysis as part of any new project we spin up.
When Should We Do Static Code Analysis?
There are three basic places we should be performing static code analysis on our code.
The first is inside our code editor. Most IDEs have support to fix our formatting and detect errors in our code as we’re writing it. We should be taking advantage of this because it will reduce our bugs before we even attempt to run our code. Most IDEs will even highlight the issues it gets back from their own and external static analysis tools.
The second is before we commit our code. We should be running as many tools as we can on the changed code before it’s committed into source control so we reduce the chance we cause the build to fail. There are ways to automate this as part of the commit creation process in git. At this stage, we generally recommend only running the tools on the files that changed because we tend to break things in the files we’ve changed, and running the tools on all files can take an annoyingly long time. The exception is when we know our change might have further ranging effects. We’ll discuss a couple of options for how to do this.
The third is on our build server. Because compute services are so inexpensive this is generally the best place to run all the static code analysis tools we can on all our code. Go hog wild to make sure as many problems can be caught at this point so they aren’t found by our end users. There are a lot of options but we’ll go over some of the more commonly used options.
What Comes Next?
Stay tuned for more videos/articles in this series as we’ll be going over some tools and techniques that can be used for static code analysis in PHP.
There are a lot of https://github.com/exakat/php-static-analysis-tools we could be discussing but we’re going to pick a couple of helpful ones.
What You Need To Know
- Static Code Analysis allows us to run checks on our code without running it
- Prevents bugs and unexpected errors
- Can validate coding standards are being followed
Scott is the Director of Technology at WeCare Connect where he strives to provide solutions for his customers needs. He's the father of two and can be found most weekends working on projects around the house with his loving partner.
- Working With Soft Deletes in Laravel (By Example)
- Fixing CMake was unable to find a build program corresponding to "Unix Makefiles"
- Upgrading to Laravel 8.x
- Get The Count of the Number of Users in an AD Group
- Multiple Vagrant VMs in One Vagrantfile
- Fixing the "this is larger than GitHub's recommended maximum file size of 50.00 MB" error
- Changing the Directory Vagrant Stores the VMs In
- Accepting Android SDK Licenses From The OSX Command Line
- Fixing the 'Target class [config] does not exist' Error
- Using Rectangle to Manage MacOS Windows