evolution

The evolution of SCA: By developers for developers

on Jan 29, 14 • by Roy Sarkar • with No Comments

The month of January is always a good opportunity to reflect, reset, and see where the new year takes us. That makes this the perfect time to kick off our new blog series on the history and evolution of static code analysis (SCA). We’ll explore why it came about, how capabilities grew as the industry [&hellip...

Home » General Industry, Static Analysis » The evolution of SCA: By developers for developers

The month of January is always a good opportunity to reflect, reset, and see where the new year takes us. That makes this the perfect time to kick off our new blog series on the history and evolution of static code analysis (SCA). We’ll explore why it came about, how capabilities grew as the industry grew, and discover today’s features that make SCA an essential and accepted part of any software development effort. Let’s get started.

The Early Years

The first generation of static code analysis tools were built by developers to solve common developer problems. Using the same techniques as early compilers, these tools focused on the low-hanging fruit, the annoying syntax and style mistakes that cropped up again and again within a file. It’s only natural that developers would use existing knowledge to automate the discovery of these mistakes in a repeatable way, so they wouldn’t have to worry about spending time testing for them.

Here’s an example of a common usage mistake that early SCA tools (such as lint, circa 1979) were designed to find:

  int foo(int x, int* ptr)
  {
    if( x & 1);
    {
      *ptr = x;
      return;
    }
    ....
  }

A regular compiler wouldn’t necessarily find an issue with the semi-colon on the third line but that one character could lead to potentially disastrous results. If this code were run, *ptr would always be dereferenced regardless of whether the (x & 1) condition were true or false. This was probably not the developer’s intent and an SCA tool would have flagged it.

These tools were brilliant in a way as they ran at nearly the same time as the code was being written (usually the process was write -> compile -> analyze and test). The developer was already knee-deep in the process of getting their code to work and fixing potential bugs before anyone else saw them. At this early stage, not only were bugs easier to fix, the number of issues introduced into the builds was reduced. This made developers very happy. A tool like lint even had a command syntax and output format that looked remarkably like the compilers that developers were already familiar with.

Unfortunately, early SCA tools had big disadvantages as well. These tools operated on one file at a time and bugs like these, while easy to introduce, were also relatively trivial to discover and fix. Especially when considering that software built from multiple source files could contain a whole bunch of interactions and dependencies between them. What if a bug occurred only when a piece of data was passed between two different functions in two different files? These SCA tools were really no more than glorified parsers, perhaps with some coding standard or style rules thrown in. Tools of this era interacted with bits and pieces of the code base only, unable to see the whole picture or provide consolidated results. As a result, these first generation tools were never able to achieve widespread acceptance with anybody outside individual developers.

Where could SCA go from here? In the next few installments, we’ll explore how tools were extended to cover broader code bases and focus on code being developed by teams of people. This introduced many benefits but also some big limitations that moved the industry away from all that was good about static code analysis.

Have you worked with SCA tools in the past? Let’s discuss your experiences in the comments below!

Read part two here, part three here.

Related Posts

Leave a Reply

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

Scroll to top