klocwork – a review

Posted on by
2

Since I wrote a review of JTest, I decided to do a review of the other commercial product I tried in the Java static analysis family – Klocwork

Installation

I ran into some trouble installing the trial Eclipse plugin. I saw a zip file to use instead of the update site.  I then unzipped it rather than pointing to it as a local install.   Which appears to work – you see klockwork show up in the Eclipse preferences, but get an error when trying to actually use it.

This gave me the opportunity to deal with their tech support.  Which was very good – they identified the problem correctly and told me to re-install properly.

Trial limitations

The trial limits you to scanning 300 files at a time.  This is perfectly reasonable – I can’t think of a reason you’d need to do more than that to see if you like a product.  I wanted to scan the same files as I had with JTest to compare output.

Since our product has more than 300 files, I thought I would just pick a few packages or classes with known issues.  I then learned they mean you can’t scan a project with more than 300 files rather than that you can’t scan more than 300 files.  Okay.  I used an Eclipse refactoring to move a bunch of packages to another project.  I’m not sure what this accomplished via the limit in the trial.  I was still able to scan everything.

The actual rules
In addition to the common static analysis rules (null ahndling, return values), some more interesting rules jumped out at me.  These include:

  1. Log forging – unvalidated input going into a log allows attacker to influence what logged
  2. If statement always evaluates to true/false – I like this was in the default rule configuration.
  3. Unchecked user input used in SQL query.  – It’s not user  input in our case, but a very good check to get you to manually review the code.

Summary

I also liked the minimizing of false positives.  Aside from my installation difficulties, I was very happy with the experience.

parasoft jtest – a review

Posted on by
Reply

I tried running Parasoft’s JTest against the modified JForum use by JavaRanch.

The first thing I did was run all the static analysis rules and got over 47 thousand hits.  Now this doesn’t mean much as some of the rules are cosmetic things and some directly confict with each other. (Use “*” for imports and don’t use “*” for imports imply every single file with get hit for one of them.  I started running all the rules so I could drill down and see what was out there.

A few of the rules were things that I had already noticed and made me cringe when reading the code.  For example, PostAction as a cyclomatic complexity (branch count) over over 40.  Ten is high.  40 is almost unreadable.

Some of the more interesting ones:

  • Found some duplicate code and string literal duplication.
  • The rules were updated for Java 5 – For example, it found I overwrote toString() but not valueOf() in an enum.
  • security rules for SQL injection
  • I really like “remove commmented out Java code” as this is a pet peeve of mine!
  • I learned that there is a problem with “double checked locking” pattern if you don’t use the volatile keyword.
  • As expected, JTest found unclosed resources, missing static keywords and the like.
  • There’s a bug in Java’s substring implementation that can cause an out of memory error.
  • It didn’t find a specific defect I was hoping to uncover when I downloaded it.  But this was more informative than not – now I know that defect isn’t in the code without having to look through hundreds of classes!

Some of the rules offer a “quick fix” where you can automatically fix the violation through your IDE plugin.  I used this to add {} to single line conditionals in 50 places without effort.

The only complaints I ran into:

  • It’s mostly updated for Java 5, but not completely.  One rule says to using StringBuffer instead of String when concatenting strings (when you should use StringBuilder.)
  • It’s slow – 5 minutes – 11 rules – 519 files.  PMD goes faster.
  • And of course – it’s expensive – but it’s intended for corporate users.  Thank you Parasoft for the trial to use on our non-commercial software!

The breadth of errors JTest can find is amazing.  It doesn’t just save you time manually reviewing code – it tells you about subtle errors you might not know about.

learning programming by asking

Posted on by
Reply

Overall, I still think that Ted Nelson had the best idea when he wrote this in Computer Lib/Dream Machines (Aperture, 1974):

The best way to start programming is to have a terminal running an interactive language, and a friend sitting nearby who already knows the language, and has something else to do but can be interrupted with questions. And you just try stuff. Till more and more you get the feel of it. And you find yourself writing programs that work.

– “Software Craftsmanship” (page 95) and available online in an article about how it applies to Ruby.

This quote was from 1974.  Since then, some things have stayed changed and some things have stayed the same.  In particular, we now have personal computers rather than interactive terminals.  Of course, a command line prompt or IDE is an interactive session – just a more powerful one.  I think the concept is just as critical as it was then.

I can think of a few ways this learning applies to me here in 2009:

  1. Summer interns – When I was a college intern, I shared a cubical with an employee.  This made it easy to ask a short question when I got stuck.  (among other benefits)  The scenario was very similar to the quote – there was someone sitting nearby that I could ask without getting up that already knew the answers.  I plowed along until I got stuck and then there was someone to put me back on the right path.  I really appreciated this approach and have voluntarily shared my cubical with our summer interns once I was the employee.
  2. Pair training – Training new developers by pairing with them allows them to see the big picture before learning all the details.  If the goal is to be able to develop without pairing, the new developer needs to become self sufficient.  I like the idea of a more gradual path to there.  Whether it be going back to my own desk for snippets or bringing my laptop to work on other stuff, it provides the atmosphere where the new developer can start applying knowledge, but having someone “on call” to ask.  Personally, I think it was more effective when I brought my laptop because it lowered the “cost” of asking.
  3. JavaRanch – “a friendly place for Java greenhorns” – an online forum doesn’t have quite the same turnaround as someone sitting nearby, it is certainly better than nothing.  Very easy questions do tend to get answers within a few hours.  It’s the same idea of having someone available to ask when learning a new language.  The internet is great for that when there isn’t something in the office.

Not all my examples just cover learning a new language, but they do show how having someone more experienced around helps with learning other things.