Products, the Universe and Everything

The Riverblade Developer's Blog

Beth demonstrating Visual Lint at the ACCU Conference 2008  Anna taking part in a discussion panel at the European Software Conference 2007 

Welcome to our developer's blog. We hope that this forum provides an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

Current Entries | Archives |

Sometimes articles take as long as products to write
Tuesday, September 30, 2008

The first time we attended the ACCU Conference back in April 2007 I was rather struck by how much I would enjoy writing for that audience. I actually started writing an article (something I've not done in a while due to time pressures) while I was there. If I tell you that I started writing it on a PDA using a stylus, you'll probably have an idea of how enthusiastic I was about it at the time).

After the conference ended the draft sat there for months. Every so often when I had a spare few minutes I'd fire up Pocket Word and write a bit more. By this year's ACCU Conference I was feeling guilty about it, and after being rather heavily "leaned on" to present a session at ACCU 2009, I decided to get a bit more serious about it. As ever, work got in the way (specifically, the development of Visual Lint 2.0) so it wasn't until the summer that I had something I was reasonably happy with.

In late August Gail Ollis wrote to me to tell me she was guest editing the next edition of the ACCU journals CVu and Overload, and asked if I'd be interested in writing a "Visual Studio 101" type article.

That was the kick I needed - and as I had something almost ready, it made sense to submit that rather than write something new. As a result, part 1 of "Taming the Lint Monster" was submitted to the editor for publication this afternoon.

I've reproduced the introduction (entitled "An All Too Common Story") below to give you a flavour of the article:
It's such a common story. Partway through a project, the company starts to become anxious about the number of defects that are being identified in the product, and how long they are taking to fix. Even worse, customers are beginning to notice.

Something must be done. Additional resources are thrown at the problem, but somehow it doesn't ever seem to be enough. The codebase is large, complex and hard to understand and maintain. It is - for all intents and purposes - a "Big Ball of Mud" (not that anyone in the company would know such a term; after all - they are far too busy firefighting to read tech blogs and keep up to date with current trends in software development).

After several months of throwing additional firefighters at the problem, someone has the bright idea? to find out just how much hidden nastiness is lurking in the code base waiting for the right moment to let loose it's wrath on the unsuspecting team.

An appropriate tool is identified and procured, and then the real fun starts - actually using it.

Inevitably, it never quite turns out the way the team (or their managers) expect. Not only does it turn out to be an absolute nightmare to configure and use (after all you never appreciate how much work compiler project files can save you from until you have to maintain something comparable yourself), but when the team do finally get it working to their satisfaction the results it produces are so volumous that nobody quite knows what to do with them. Worse, they contain some really bad news (TM).

As all too often happens, dealing with the issues the tool raises is deemed to be a) too expensive, b) too risky and c) not as much fun as writing new copy-paste code (though nobody is ever quite honest enough to admit to the latter).

The team conveniently forget about the whole experience and go back to compiling at warning level 3 as they always have done. The installation disk for the offending tool is quietly hidden away in a desk draw and forgotten...and of course, the Big Ball of Mud grows ever bigger until the inevitable "lets just re-write it in language 'X'" event a year or two later. With an eye on what language 'X' would look like on everyone's CV, of course...

But it sure did seem like a good idea at the time...
Incidentally, if you are interested in software quality and innovation and haven't joined ACCU, you really should...

Posted by Anna at 19:40 | Get Link


Detecting unused include files in C++ projects
Saturday, September 20, 2008

Sometimes the time to build or analyse your code can be a real pain. In C++, one of the things that can contribute to this is excessive header file nesting. As such, it is a good idea to take a look at your include file dependencies once in a while. Of course, one of the obvious and low risk things you can do is to remove any #include directives which aren't required.

You may not be aware that PC-Lint can detect unused header files if you configure it correctly. The main PC-Lint message you need to know about is 766 ("Header file not used in module"), but there are also ones for more subtle issues such as 964 ("Header file not directly used in module") and 966 ("Indirectly included header file not used in module").

All are informational, so if you have your warning level turned down to warnings or errors only (for example via -w1 or -w2) you simply won't see them. Of course, if your codebase has not been analysed before or is "noisy" turning up the warning level is likely to result in the issues you are looking for being drowned by others.

Fortunately, there is a simple way to show just the unused header file issues. All you need to do is set the warning level to 0 (which turns off everything!) and enable just the ones you are looking for - in this case only 766. In Visual Lint you can do this by defining custom analysis options -w0 +e766 on the "Command Line" options page:

Setting up analysis options for unused header file detection

When you re-analyse the code (use single file analysis, and make sure all projects are set to inherit default custom analysis option settings), the only issues shown now will be those messages you have enabled:

Once each file has been analysed, those containing unused header files will be plainly visible

Although I've used Visual Lint to illustrate this, you can also do this directly from the PC-Lint command line. You can also use the same approach to detect any specific issue - so if (for example) you want to detect all of the C style casts used in a C++ codebase you would use -w0 +e1924.

By the way, if you are looking at include dependencies within your code, you really should be aware of Profactor Software's IncludeManager:

Profactor Software's Include Manager

Like Visual Lint, it is a Visual Studio add-in. Visual Studio 2003 and 2005 are supported, with Visual Studio 2008 support in beta. Highly recommended.

Posted by Anna at 14:21 | Get Link


It's Official - PC-Lint 9.0 is here
Monday, September 15, 2008

If you have visited the Gimpel website over the past few days, you may have noticed some information on PC-Lint 9.0 leaking out. Although we have known about PC-Lint 9.0 for some time (we were one of the beta testers), we were unable to talk about it until the formal release.

Since Gimpel have now made their formal release announcement we are now able to discuss it freely.

We have been running beta versions of PC-Lint 9.0 here for several months now, and I have to say that it is a huge improvement over PC-Lint 8.00. Not only are there a whole bucketful of new messages (146 in fact), but the new version supports much improved variable checking, thread analysis, detection of pointer and reference anomalies and MISRA C++ to name but a handful of the major features. Furthermore, previously undocumented message suppression options such as -etype (which works a treat with boost::shared_ptr<*> and message 1746...) are now fully supported.

Highly recommended.

Posted by Anna at 19:07 | Get Link