Polishing

Hit a deadline early this afternoon and hadn’t chased up some requirements so I ran out of things to implement. Faced with a couple of hours spare I whipped out Gimpel Lint and started to polish…

I’ve been a fan of Gimpel’s PC Lint product for several years. It’s like turning compiler up to warning level 11. I try and keep all of my code passing through it without any warnings. This means maintaining suppression files and adding warty comments into the source code. I decided that I’d prefer the explicit warty comments to a suppression file that supresses lots of things… I quite like being reminded that I forgot to make a single parameter constructor explicit (yet again!) or that I’m ignoring a return value (why am I doing that?). I then either fix the problem or add a warty comment… The warty comments act as a constant nag for me to fix the problems in a better way; or just decide to turn off a particular warning for good, but then when might it be useful?

I like the over the top bleating that Lint does because it makes me look critically at the code and ask myself “why is it OK to turn off this warning here?”. It makes me think. I like things that make me think. It also comes up with some fine suggestions, it’s great at chasing ’this could be const but isn’t’ chains right up the call stack. You add a const and it bleats about everything else that could now be const. It’s like pair programming with a hyper-critical partner… Wonderful stuff.

It doesn’t often find bugs, but when it does they’re the subtle ones that often otherwise take an age to find; Initialiser list inversions, calls to virtual functions in ctors and dtors, methods being hidden in derived classes. Stuff that you often look at and think is fine because you’re not tuned in to the badness.

But today it found a stupid bug. A delete that should have been a delete [], my excuse is that it’s in a piece of code that doesn’t get executed very often and gets looked at even less… Still, it’s fixed now.