How to find bugs in your code before your customers do

In addition to writing articles and presenting at conference sessions and training seminars (where most people may recognise me from), I'm also active as a developer and consultant. This often means writing code in a team, using other people's code, and making sure other people can use my code. I'm also sometimes asked to do a code review; examining someone else's code, giving feedback as to which portions should require attention when it comes to maintainability or potential future migration (to Linux, .NET, CF, you name it). Code Reviews are often a bit sensitive. There are some customisable guidelines, like indentation level, naming conventions (for components but also forms, units, classes, methods, fields, local variables, etc.) and as long as a team is consistent, there's no right or wrong (although sometimes one can believe to be more right than another - or less wrong). Another area of code reviews is the time consuming one, where you have to walk through the code and look for real issues like unreachable code, functions that don't always produce a result, etc. Some of these issues can be detected by making sure the Delphi compiler is allowed to produce all hints and warnings (the only warnings you may consider turning off are the unsafe type, code and typecast warnings, but only if you are 100% sure you will never want to migrate your code to the .NET Framework), but there are far more potential coding errors than the Delphi compiler can detect.

CodeHealer
Why this long introduction, you may ask? Well, my life has just become a lot simpler with CodeHealer from SOCK Software. Note that CodeHealer has only recently been released (at Borland DevCon 2005). In fact, it's been in beta for over a year now, to ensure a perfected code analysis and verification tool as result (I reckon CodeHealer is used to report on itself as well).

Project Metrics and Project Analysis
CodeHealer can be used to examine Delphi source files. At this time only for Win32, but support for .NET is already in the works. You can get two kinds of reports from CodeHealer: Project Metrics and Project Analysis. The Project Metrics report lists information like the number of source files, applications, libraries, packages, units, source lines, significant comment lines (including a percentage of comment lines vs. code lines), and metrics regarding your classes, interfaces, objects, properties, different kinds of methods, branch points, keywords, literal values for hex integers, integers, reals and strings.
The Project Analysis examines the source code for specific rules, divided into Audits and Checks. Project Analysis Audits consist of rules that guard the code quality, while the checks contain rules that concern potential coding errors. Example of audits that are performed are the use of deprecated or experimental keywords and language constructs, platform dependent items, Delphi keywords or directives that are used as identifiers (for example a local variable called Str or Currency), and hidden identifiers (for example because they are redefined at a lower scope).
Project Analysis Checks contains rules to report any code that might contain errors like uninitialised or unused variables, array indexing errors, undefined function results (when not all branches return a result for example), if statements followed by empty code, and finally checks to report any unreachable code.

Failures
For each failed audit or check, you can see the rule that was violated, as well as the exact source line that violated the rule. This means that you can easily see what you've done wrong and where, and can fix it (so it won't show up next time).

There are some infrequent occasions where you might encounter a "false positive", i.e. a report of a failed check or audit when in fact you didn't fail it. These have happened to me twice (while CodeHealer was still in beta), and can be send as feedback to the CodeHealer team (who will then work hard to ensure these false positives don't reappear in updates). Speaking of updates: CodeHealer can be configured to automatically check for updates, so you can be assured that you'll always work with the latest checks and audits.

The use of CodeHealer may not be enough to replace a human code review, but it will give you a really good start. And even better: a CodeHealer analysis only takes a few seconds to produce a report that you can use to determine the overall quality of your code. At the end of the day, CodeHealer Project Metrics and Project Analysis reports can really help to improve the quality of your code, and increase the chance that you find potential bugs (and can fix them) before your customers find them. And I guess that may be the best benefit, so perhaps everybody should use CodeHealer to analyse and verify their projects.

CodeHealer 2.0 was officially released at the Borland Developer Conference 2005 in San Francisco. Currently, it supports Delphi for Win32 only, although Delphi for .NET support is in the works (and is promised to become available as a future update). I can highly recommend the use of CodeHealer as a Quality Assurance utility to increase the quality (or at least the awareness) of your Delphi code.
For more information and pricing information, see the SOCK Software website.

Latest News: CodeHealer version 2.1 was released at the end of March 2006. Check out the SOCK Software website for more information about what's new in version 2.1.

(Bob Swart)