Next week I’m heading out to the Software Assurance Forum (use SOF96945 for the conference code) in Washington D.C. (well, actually Arlington, Virginia, but D.C. sounds more glamorous). If you’re not familiar with what the SWA is, in a nutshell, its key objective is to encourage software developers to raise overall software quality and security from the start, rather than relying on applying patches to systems after vulnerabilities are discovered.

Anyways, while I’m there, I’ll be taking part in 2 speaking opportunities. The first will be as part of a 6 person panel discussion entitled “Understanding Technology Stakeholders: Their Progress and Challenges” (10:30 – 12:00 on Wednesday). The panel is made up of stakeholders from varying disciplines such as industry, academia, standards, and government. A good well rounded panel should provide for an interesting and entertaining hour and a half.

My second session (Friday at 2:20) will see me fly solo as I discuss our (Klocwork’s) experiences and observations as they relate to SATE. I’m not given much time, so I’ll be revving up the motor mouth to make sure I get our points across. I have a sneaking suspicion I just *may* go a little OT.

So, is anyone out there also going to this event? If so, drop me a line either by email (todd.landry@klocwork.com), or Twitter (@todd_landry) and perhaps we can get together to chat. Look for my next blog next Thursday, as I will recap the panel discussion and the other sessions I attend at this event.

In this 3 part blog series I want to cover general misconceptions with static analysis coverage.  This will include a discussion about:

• compiler warnings available,
• different types of style issues including coding standards, and
• your available options to fit them into your formal process.

Very often customers ask why we don’t cover specific checkers.  We always get great feedback on high value checkers that they would like to see.  But occasionally we get the request to find simple compiler warnings or code style issues.

For the first part of this series I want to focus on compiler warnings.  These are not the compiler errors such as syntax/parse errors you get with a compiler.  Instead, I want to concentrate on those pesky compiler warnings that still let you build your application, when you really know you shouldn’t.  We have all experienced compiler warnings that are just plain confused with your code.  But on the whole, you are guaranteed to find some pretty big blunders.

Most modern compilers focus on providing more details about compiler warnings.  These can be very valuable as it helps find many of those plain dumb mistakes.  It varies by compilers, but many find things such as constant expressions from conditionals, returning from a void function, assignment in condition (use = instead of ==), suspiciously-placed semi-colon and many, many more.

To find some of the issues, you usually need to provide a compiler flag -Wall.  For example:

    gcc -c -Wall foo.c 

Make sure you read your compiler documentation for available warnings.  Here is the gnu gcc compiler and Microsoft cl compiler docs.

Given that every compiler on the market provides its own “checkers” for compiler issues, does it really make sense for static analysis to get in there and detect these issues again?  I strongly believe that every developer should ALWAYS clean up their compiler warnings before going onto static analysis.

But you will still find static analysis tools providing these capabilities.  Why?  Well, first and foremost, not every compiler has the capability to find simple coding issues.  The other reality is that not everyone checks the compiler warnings…(we all know who we are).  Or sometimes you just want to run one tool.  In other words get the more complex bugs with static analysis along with the compiler warnings.  It is for these reasons that static analysis tools have introduced many of these low-level issues.

For the next part of this blog series, I want to go into the details of compiler warnings and some of the things that coding standards are doing as well.

In a previous post I provided the top 5 C/C++ quality bugs that I that I see time and time again looking at customer code.  Time for the C# version:

1.    Null pointer exceptions from a method

1                  public class A {
2                      public A foo() {
3                          if (flag)
4                              return null;
5                          return new A();
6                      }
7
8                      public void var() {
9                          A a = foo();
10                         if (flag)
11                             a.foo();
12                     }
13
14                     private int flag;
15                 }

This is the most common issue I see.  In this example a warning is issued at line 11 for a possible null pointer exception.  Essentially there is a potential for a null value from the method foo().  I believe I see these issues more than any others  because of the inter-procedural context of this issue.  This example is quite simple, but where you can easily get lost is when that null value is coming from a long method call chain in multiple classes.

2.    Resource leaks

1  using System;
2  using System.IO;
3
4  namespace LeakExample
5  {
6      class Test
7      {
8          public String Run(String name)
9          {
10             StreamReader reader = new StreamReader(name);
11             String result = reader.ReadToEnd();
12             reader.Close();
13             return result;
14         }
15     }
16 }

I think for most of us this is pretty easy to see.   An object of ‘StreamReader’ type is allocated and its reference is assigned to the ‘reader’ member. If the call to ‘ReadToEnd’ throws an exception, control is transferred out of method ‘Run’, variable ‘reader’ goes out of scope, the object referenced by it becomes lost, but related resources are not disposed.  See my previous blog post on how some people miss this and what you need to do to fix this.

3.    Forward null pointer exception

1                  public class A {
2                      public void foo() {
3                          A a = new A();
4                          if (a == 0)
5                              if (flag)
6                                  a.foo();
7                      }
8                      private int flag;
9                  }

This is another example of a null pointer exception with a twist.  In this example the class data member ‘a’ is compared with 0 value at line 4, and therefore may still be expected to be null when it is dereferenced at line 6.

4.    Reverse null pointer exception

1                  public class A {
2                      public void foo() {
3                          A a = null;
4                          a.foo();
5                          if (a == null)
6                              a = new A();
7                      }
8                  }

Yes, another null pointer exception (getting a theme here?).  Same idea at #3 but in reverse order.  Here they dereference the data member ‘a’ at line 4 but later check for null at line 5.

5.    Empty catch clause

1  class FileHandler {
2      public void Open(String name) {
3          try {
4              // opening file ...
5          } catch (FileNotFoundException e) {   // defect - no statements in the 'catch' clause
6          }
7      }
8  }

Okay, so not exactly the big impact as the top 4, but I just had to mention it.  I’m always guaranteed to see some of these.  Granted they are maintainability issues more than anything else, but c’mon they are there for a purpose.
As promised, I did say that I would post the Java version soon.  It is next…

A recent article brings up some interesting discussion.   I definitely agree that high quality code can be created without tools or any automation.

But in organizations where you have tight deadlines, fewer developers and more features than ever, something has to give.  To me, saying that you don’t need tools or automation is like saying you want to dig a hole for your pool with a spoon OR climb Mount Everest jumping on one foot OR you get the point…Sure you can write high quality code, but how productive will you be when you have your customers on your ass for the next feature?

Additional comments by the author goes on to say:
The very point of a tool is to change a process. Usually the goal is replacing a manual process, with an automated process.

Well, how is this changing your process?  Isn’t that taking something that may take 1 hour manually down to 1 minute something that is desirable?

Either way there are plenty of tools that don’t change your process.  The ones I’m very familiar with is static analysis tools.  The whole point of them is to extend and embrace your existing process.

But with that said, let’s look at how some IDEs have evolved.  Going from a text editor to an IDE, I guess is changing your process.  But what are the reasons for this?  A more targeted debugger, auto completion, refactoring etc.  What does that do? It makes you code faster and smarter.  I think I’m more than happy to change the process for that.

Here’s a short blog review of Klocwork Solo by Jeanne Boyarsky. Klocwork Solo is a downloadable Eclipse plug-in for Java. Aside from a few installation hiccups, it’ s a good review with kudos for the range of checkers we provide in the default configuration.

Try it out yourself and let us know what you think.

As a developer of static analysis tool for mainstream statically-typed languages, like C++ and Java, I was wondering for quite a while about how well static analysis applies to dynamically-typed languages, like Ruby and Python. And recently, I have come across this interesting project on GitHub: Reek – Code smell detector for Ruby. Well, I suppose that’s just a fancy way to name a static analysis tool.

What can Reek detect? It does not do heavyweight data/control flow analysis, so the list is not very exciting:

• Code Duplication – AFAIU, it’s not very accurate, ’cause Reek only tracks duplicated method calls (sic!)
• Some design anti-pattens, like Feature Envy, Utility Function, Nested Iterators and Control Couple
• Some metrics-based stuff, like Large Class, Long Method and Long Parameter List
• (Arguably) bad coding practices, like Uncommunicative Name

Interestingly, despite the poor set of features, compared to modern C++/Java static analysis solutions, Reek gets positive feedback from Ruby community. Some take it to the extreme – integrate Reek into the build and handle code smells as failing tests, and that of course breaks the build every time a new code smell is detected. So, is Ruby community starving for real static-analysis tool?..

This question forced me to run a quick research on what’s the current state of static analysis tools for dynamic languages. I was able to find the following tools for Ruby and Python:

Python tools appear to be pretty conservative about program analysis and try to “compensate” the dynamic nature of the language.

• PyChecker and pylint – These two tools aim to provide the same kind of warnings/errors, a compiler for statically-typed language would report automatically. For example: too few/many arguments in a method call, unused variables, using return value of a method that does not actually return any value, etc. One of the checkers for pylint, in fact tries to “simulate” static type system by using type inference, and detect missing members and functions, and this, in turn, might involve some elements of data flow analysis. Beside that, there is a bunch of metrics-based rules that can be checked automatically – you can put a limit on number of methods in a class, number of variables in a function, size/complexity of a function etc.

Tools for Ruby introduce the same kind of checks, but from slightly different angle. Rather than adopting the lint metaphor (a complementary tool, finding bugs/errors that compiler does not detect), the tools are positioned to find design flaws.

• Reek – See above.
• Flay – Checks code bases for duplicates. Aims to enforce the DRY design principle.
• Flog – A tool to spot the most complex functions in your code. Metric-based.
• Roodi – Supports a bunch of simple syntax-based and metric-bases checks. For example: assignment in condition, case missing else, max method/class/module line count, method/class/module name check.

Having looked through these projects, I’ve come to find two things:

First – There are some tools that do static analysis for Ruby/Python, but they are quite simple and don’t do (or don’t try to do?) any advanced heavyweight analysis.

Second – What Ruby/Python developers want to be automatically found in their code, is quite different from what their C/C++ fellows expect from a static analysis tool. And that is because the languages and programming cultures are quite different. For example, in Ruby there is no such thing as:

• null pointer dereference – nil is a first class object
• array bounds violation – array would return nil when index is out of bounds
• uninitialized variables – all variables are automatically initialized with nil
• memory leaks – garbage collection takes care of that

But they do have errors in their programs, don’t they? Yes, but Ruby/Python developers rely on tests pretty heavily. In fact, some claim, that tests are the only right way to deal with bugs in your program. This way a tool for automatic error detection might even be considered harmful – just because it can be used as an excuse for not writing tests.

So, what kind of job is left for a static analysis tool? Well, detect design flaws, a.k.a. “code smells”. In other words – automatically find subjects for refactoring (a change that does not affect program functionality). This way static analysis tool fits naturally into Red/Green/Refactor cycle.

Another possible area where static analysis based error detection can prove useful is security vulnerabilities – it is pretty hard to spot all corner cases up-front (or through exploratory testing), just because security is a complex domain and requires good amount of knowledge and expertise.

Interesting article on static analysis tools to help find concurrency issues.  These so called “Parallel Lint” tools are specific to finding these types of issues.  Overall there are some great discussions on certain tools, and it is always nice when Klocwork gets mentioned.  But my problem is with the categorization of these tools.  It always makes me feel sick every time someone puts Klocwork in the same category of “powerful static analysis” with JLint, C++Test, FXCop and my favorite PC-Lint.

This is a point I feel keeps getting lost with modern static analysis tools today.  Forget the Lint of the past or these other tools, their focus is on file by file analysis.  These old tools are doing simple grep type analysis.  Sometimes where you’re lucky you get a little bit of control flow with a dash of data flow analysis.  But plainly they are missing the deep inter-procedural analysis and techniques that are used with modern static analysis tools today.  I’m hoping the message is getting out there that static source code analysis is far far beyond Lint and is providing the context you never had before.

When I first started at Klocwork, I didn’t really know a lot about source code analysis. I understood the basic concept of how it finds bugs in software, but that is was essentially it. Sure I knew about Memory leaks, but I truly believed that they were only found a day or two before the GA date…at least, that was when our testing team always found them.

In one of my teams prior to joining Klocwork, we used Scrum. We were hard core, with daily 15 minute scrums, retrospective meetings, sprint planning sessions, defining “done”, secret handshakes, the whole 9 yards. We also broke our features down into small tasks, and those tasks were written on cue cards and then stuck to a big wall for all to see. What a great way to see the progress of a sprint. We had green cards for development tasks, blue cards for testing, yellow cards for documentation, and red cards for bugs. I remember how after 2 or 3 days into a sprint, the red cards would start showing up, and developers would then start addressing them. Since one of our team ‘rules’ was each person could only have a single task checked out at one time, our developers had to check-in the green card they were working on in order to tackle a red card. By the end of a sprint there were always a number of red cards left, which by definition, needed to be addressed first in the next sprint. I’m sure you can imagine the enthusiasm of heading into the next sprint knowing there was a wall of red cards to address first.

Anyways, my first few weeks at Klocwork consisted of talking with a lot of people; customers, prospects, etc. These people knew source code analysis, but they only knew the traditional way of source code analysis (SCA), and not the new generation of SCA where developers check their code before they check-in their code. I remember thinking I must be missing something…why is this so hard for these people to understand?  Source code analysis turns a lot of those red cards into green cards.  For more info on how SCA and agile can work together, check out this webinar I recently did…

In response to Jason’s post about false positives.  First of all there is a general misconception of false positives.  Modern static source code analysis tools have changed the game.  It is not the Lint tool of the past, a focus with deep inter-procedural technology has placed the requirement that static tools today produce more real issues than false reports.

With that said, Jason is right, large code bases never running static analysis will produce a large number of issues no matter how accurate it is.  Even though static analysis tools do provide a number of ways to manage this (and Jason talks about one) it does make sense to put this in your code reviews. You are looking at legacy code but if you are doing code reviews then you must have changed something with that legacy code.  Therefore having those bugs visible to you during the code review could suddenly now apply.

Jason certainly hits the nail on the head.  Automation, specifically using static analysis, is key and it should be tightly integrated with your code review. Although we need to be careful where we label source code analysis.  Static source code analysis certainly can find those low level issues such as labeling your local variables correctly, but it goes beyond simple code style issues.

Where static source code analysis can really help is with the deep inter-procedural context that it can provide.  For example, during a code review you go through some code with a number of function calls.  Hopefully you know what each and every function is doing…but do you really?  This is where the deep analysis of static source code tools can help.  It can help you identify that there may be an issue in the code review and that issue happens to show that a function is returning NULL.  Uh oh, potential null pointer dereference on our hands.

Now add code reviews with other static source code technology, such as full source cross reference information, flowcharting, impact analysis for any function/methods and architectural representation to show you the full context of the system.  Now you’re talking powerful.