Given the great emphasis Agile teams place on the importance of software testing, it is surprising that organizations don't invest more time and money in static software testing tools. Of course, with Agile testing, the focus is heavily on user acceptance, which is a pretty high-priority topic, whereas static code analysis is more of an insurance policy against putting bug-ridden code into production. And actually, bug-ridden isn't exactly the right term. After all, it only takes one unidentified bug to either bring down an entire production system or, even worse, allow hackers to hijack the software and cause untold millions of dollars in damages.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Introducing static code analysis
So what exactly is static code analysis? "It's about taking a look at your programs from the source code level," said Klocwork engineer Larry Edelstein when TheServerSide got a chance to speak with him at EclipseCon 2014. "We are looking at all of the different, possible control flows that can exist in your software. We look at the values variables can take as they flow through your program, and then flag the types of errors that can occur based on specific conditions there."
It's about taking a look at your programs from the source code level.
While static code analysis might not be a term that's on the tip of every software developer's tongue, it's a process that every software developer is familiar with at some level. Every Eclipse developer has seen a little warning next to a variable that hasn't been initialized yet, or an unreachable catch block in their exception handling procedures. "We get buffer overflows, we see a lot of those. We see null pointer dereferences," Edelstein said about some of the more common problems that are identified in the code. But of course, it's the more esoteric problems that static code analysis tools like Klocwork can identify that brings the most value.
"We note that there are certain sources of Strings, like ones coming in from the HTTP layer, that are tainted," said Edelstein about the tool's ability to identify potentially unsafe data that might be entering the system from unverified or unreliable sources. "We also note that if you pass one of those tainted Strings into a JDBC method, you have the possibility for SQL injections." And this is simply one example of the many potential threats a static code analysis tool can quickly identify.
Like an insurance policy for source code
Given the number of high-profile companies that have been in the news lately, embarrassed by software glitches that static code analysis tools could have easily caught, it is hard to believe that more organizations aren't using these types of tools. They easily integrate into IDEs like Eclipse, IntelliJ IDEA and even vi and Emacs. And the tools can also integrate seamlessly into continuous integration tools. "Most users write jobs in Jenkins that call our command-line tools," said Edelstein about the integration of source code analysis tools with continuous deployment processes.
The fact of the matter is, it's impossible, given the number of software flows in modern applications, for any team of developers to ensure that human testing procedures will catch 100% of the bugs that make it into enterprise software. If your organization is seriously interested in approaching the limit of completely bug-free code, a static code analysis tool is an absolute requirement.