I’ve been a big fan of Gimpel Lint for years. It’s a great static analysis tool for C++ and it can locate all kinds of issues or potential issues in the code. My problem with it has always been that it’s a bit of a pig to configure and run, more so if you’re used to working inside an IDE all the time. Several years back I had some custom Visual Studio menu items that I’d crufted up that ran Gimpel Lint on a file or a project and some more cruft that converted the output to something clickable in the IDE’s output pane. This worked reasonably well but was complicated to maintain and easy to forget about. There was nothing to encourage you to run Gimpel Lint regularly and if you don’t do that then the code starts to decay.
Visual Lint, from RiverBlade is, at heart, simply a Visual Studio plugin that integrates other static analysis tools into the Visual Studio IDE. However, the simplicity of the idea belies the value that it provides. Visual Lint makes Gimpel Lint a usable tool within the Visual Studio IDE. For me it has taken a very complex and hardly ever used tool which I always meant to use but never did and turned it into something that I use regularly and that is easy to run.
Gimpel Lint is still complicated to configure and it can be depressing when you first run it on a large codebase but once integrated with Visual Lint and run regularly it becomes a usable and powerful addition to your toolbox.
Now that I have Visual Lint running in my IDE and most of my code abiding by my in-house Gimpel Lint rules I suppose I should look at RiverBlade’s LintProject tool and get my build servers to report on Lint breaks…