podium

The evolution of SCA: Fast and Furious!

on Feb 28, 14 • by Roy Sarkar • with No Comments

This is the final part of our series (read part one here, part two here, part three here) about the history and evolution of static code analysis (SCA). We’ve explored the progression of tools and methodology over the past few decades, going from small utilities built by developers to comprehensive tool suites that...

Home » General Industry, Static Analysis » The evolution of SCA: Fast and Furious!

This is the final part of our series (read part one here, part two here, part three here) about the history and evolution of static code analysis (SCA). We’ve explored the progression of tools and methodology over the past few decades, going from small utilities built by developers to comprehensive tool suites that help entire teams deliver reliable and secure code.

As discussed in our last blog post, most modern SCA tools force teams to perform analysis after check-in, to cover as many control and data interactions across the code base as possible. The trade-off is that issues are found later in the software development life cycle, at a greater cost to fix and developers find themselves bound to someone else reporting problems and expecting fixes.

The next generation of SCA tools build on the technology of deep and comprehensive project coverage while also bringing control and results back to the developer’s desktop. This approach finds issues earlier and fixes stay within the expertise and schedule of the person that best knows how to deal with them. There are two methods to achieve this:

Distributed system context – creating an awareness of all functions and behaviors across the system by connecting code on developer’s desktops through a centralized server.

Peer-to-peer context – sharing analysis results across all local analysis engines, giving everyone an awareness of potential problems.

With analysis and issue reporting happening right at the developer’s desktop, you may think we’re at the earliest possible point to find and fix problems. Yet there are two more techniques to squeeze in benefits even earlier.

Embed the analysis into your IDE – Most developers today work in some kind of IDE, whether it’s Microsoft Visual Studio, Eclipse, IntelliJ IDEA, and so on. Rather than forcing developers to leave these environments to run an analysis tool, embedding the tool into the IDE keeps the power within the control and interface they’re familiar with. Of course, it still makes sense to retain a command-line interface for those who appreciate that flexibility.

On-the-fly analysis – Taking advantage of modern computing power, analysis results can be displayed as the developer is writing code in their editor. Just like a real-time compiler or spell checker, issues can be flagged as fingers are flying across the keyboard, giving an immediate awareness and context to the problem.

Klocwork's integration with Visual Studio

Click to enlarge

These two techniques give an immediacy to problems and a timeliness to fixes at literally the earliest possible point in the development life cycle. This brings testing to the developer, a key tenet of Test Driven Development. Combine these benefits with an awareness of code and issues across the project and any developer can figure out where, why and what is needed to fix potentially disastrous security, reliability and programmatic errors.

To learn more about how these features work and how your team can use them, check out the following resources:

When, Why and How to Leverage Source Code Analysis white paper (PDF)

Static Analysis: Dispelling the Myths webinar

Klocwork Insight Overview video

Have any more ideas on how to make static code analysis better? Let’s discuss your thoughts in the comments below!

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top