D:\HOME\cwj>cwj demo.java
You do not have a password.

Dances With Wizards
Technical support was knowledgeable, and the wait to talk to a live human was short. Once you get past the password issue, things are relatively straightforward. (Passwords are locked to your hardware machine ID, and have an option for timed expiration.)

Once you have a password, CodeWizard for Java is run in stand-alone mode for source code analysis by typing cwj wherever you would type your normal Java compile command (e.g., javac); so, cwj demo.java checks the source file demo.java. You can get fancier with the command line. For example, you might try something like:

cwj PrimeNumbers.java -Zoi "ClassNameRegExp ^[a-z]" -Zoi
 "suppress item 2"

You can also run CodeWizard for Java as an integrated tool that checks your code and then calls your Java compiler, thus:

cwj -Zoi "analyze_only off" demo.java

However you choose to invoke CodeWizard for Java, you can view its output in a graphical browser or you can send it to stderr or to a report file as an ASCII report. CodeWizard for Java also has configuration files that allow you to specify the options you desire once, rather than on the command line each time using the -Zoi parameter.

CodeWizard's graphical browser, Insra, is the graphical user interface common to all the CodeWizard for Java products. Insra allows you to view the error messages (or code commentary, call it what you will) and has buttons for navigation and for suppressing items that are displayed.

A Few Potholes
I ran cwj on the demo.java file, and got Insra to display the results. I then clicked on the error message in Insra, and a window appeared with a more thorough explanation. I tried to look up Item 30 in the provided Help file, and was surprised to see that there was no apparent entry for Item 30. However, tech support suggested double-clicking a related entry, Item 29, and sure enough, Item 30 was explained there. I consider the help file to have a bug, in that the heading for Item 29 should have indicated it was for 29-30, as do headings for other groups of items.

Tech support also indicated that there were really 65 Items, not the 39 visible to me. It turned out that the version of the software I received in October contained files from June, and there was a newer release in September. The ParaSoft support site allowed me to download an updated version in self-extracting executable form (slightly more than 3MB). This update contained the additional items, and otherwise seemed to offer the same functionality as the earlier version I'd been working with.

Up and Cruising
CodeWizard for Java integrates to some extent with Microsoft Visual Studio, but it doesn't know anything about Visual Café. So, I decided to throw some existing Java code at it and see what happened. The code I used was for a GUI form-related application. CodeWizard for Java analyzed the code and displayed summary results in the Command box from which it ran, with details in the Insra GUI, all within the space of a few seconds. The summary statistics were:

D:\HOME\cwj>cwj *.java
CodeWizardJava parsing ...
checking for rule violations in D:\HOME\
cwj\FileServer.java
checking for rule violations in D:\HOME\
cwj\InfoID.java
checking for rule violations in D:\HOME\
cwj\KButton.java
checking for rule violations in D:\HOME\
cwj\MessageBox.java
checking for rule violations in D:\HOME\
cwj\TaxClient.java
checking for rule violations in D:\HOME\
cwj\TaxImpl.java
checking for rule violations in D:\HOME\
cwj\TaxInfo.java
checking for rule violations in D:\HOME\
cwj\TaxMenu.java
checking for rule violations in D:\HOME\
cwj\TaxServer.java
Summary metrics:
	Number of Classes:	9
( Final Classes:  0 )
	Number of Interfaces:	0
	Number of Methods:	47 
( Final Methods:  0 )
	Number of Static Methods:	1
( Final Static Methods:  0 )
	Number of Instance Variables:	32
( Finals:  0 )
	Number of Static Variables:	25  
( Final Static:  0 )
	Number of Lines Parsed:	948
	Number of Files Parsed:	9

Figure 1. Insra displays each violation it finds and allows you to drill down to the actual code.

Rules!
What We Need are Rules!
CodeWizard for Java incorporates a number of items or recommended coding practices; violations of these rules are reported by the tool. The documentation lists 39 of these items and, if you run off the installation CD I received, these are the items that the tool checks:

Item Description Violation Enabled 1 Avoid
 unused variablesPV X 2 Explicitly initialize all
 
variables. PV X 3 Switch statement with bad case.
 PSV X 4 Make class names match their 
filename.
 I X 5 Avoid hiding inherited instance variables.
 PV X 6 Avoid hiding inherited 
static member
 functions. PSV X 7 Constructor should explicitly
 initialize all data members. 
V X 8 Instantiated
 classes should be made final. I X 9 Avoid
 assignment within an if condition. 
V X 10 Avoid
 public and package instance variables. I X 11 List
 all public and package 
methods/data first. I X 12
 Avoid hiding member variables in member funct-
ions. PV X 13 Implement 
interfaces nontrivial-
ly or abstract. V X 14 Use "equals" instead of
 "==". PV X 15 
Use "Stringbuffer" instead of
 "String". I X 16 Provide "default:" label for each
 switch 
statement. PV X 17 Provide incremental
 in for-statement or use while-statement. I X 18
 Enforce 
name format of classes. V X 19 Enforce
 name format of instance variables. V X 2 0 En-
force name 
format of methods. V X 21 Enforce
 name format of local variables. V X 22 Enforce
 name format of 
interfaces. V X 23 Enforce name
 format of method parameters. V X 24 Enforce
 name format of exceptions. 
V X 25 Enforce name
 format of class variables. V X 26 Enforce name
 format of class methods. V X 27 
Unused throws
 statement. V X 28 Close stream in finally block.
 V X 29 Unused private class variable. 
V X 30 Un-
used private class methods. V X 31 Explicitly ini-
tialize all static variables. V X 32 
Distinguish
 between javadoc and ordinary comments. I X 33
 Bad tag in javadoc comment. I X 34 
Provide
 javadoc comment for each top level class and in-
terface. I X 35 Provide javadoc comment 
for
 method and data. I X 36 Avoid declaring vari-
ables inside a for loop. PV X 37 Avoid 
declaring
 variables inside a while loop. PV X 38 Avoid dan-
gling else statements. PV X 39 Avoid 
for-state-
ments with empty body. PV X Severity
 Explanation: I - Informational, PV - Possible Vi-
olation, 
V - Violation, PSV - Possible Severe Vio-
lation, SV - Severe Violation.

if (foo = 3) { //do some stuff

Items 18-26 may give you pause if you don't want some tool telling you what naming conventions to follow. However, CodeWizard for Java doesn't do that: what it does is require you to specify your own naming conventions using regular expressions. The manual provides good examples of sample regular expressions, if this powerful UNIX feature is not intuitive for you.

ParaSoft's manual notes that if you would like additional items not included in CodeWizard, you can write your own rules using CodeWizard's optional API feature. You can also order custom rules from ParaSoft's Web page which includes a mechanism for submitting requests for rules to be included in the product; because Java is still a new programming environment, ParaSoft's openness to programmer input is to be commended. A search of the documentation and Web site for information about the API turned up nothing useful, however. ParaSoft's technical support personnel indicated that APIs for writing your own items or rules are available, along with documentation, at $12,000 each for Windows NT or Windows 95. ParaSoft also confirmed that they would customize CodeWizard for Java on a paid basis for an organization, but could not quote prices as the cost would depend on the number and complexity of the custom items and the extent of customization.

Suppressing Warnings
Given all the things it complains about, CodeWizard for Java does allow you to suppress warnings. The suppression is driven by a rule number, rather than by warnings in particular modules, although it is possible to tell the product to ignore files or packages. This is an improvement over the kinds of warning levels we're used to in compilers. With a little work it would be possible to get CodeWizard for Java not to report certain rule violations based on who generated the code, by organizing the code, or by explicitly excluding the files. I don't want CodeWizard for Java to tell me anything about the code generated by the gaggle of other wizards and operating environments we have to deal with, so I'd like it not to do much of anything with generated code or, if it must report, only report once. On the other hand, the code that's written by hand should be subjected to a different and potentially more rigorous set of rules.

Consider a situation where names of classes written by the team's programmers follow a different naming convention from that used by the compiler and/or library vendors; you can specify a regular expression for your standard, and then sit through the errors reported on 3rd-party code; or you can write a regular expression that allows both standards, and mask situations where your team improperly adopts the 3rd-party standard, or you can just turn this item off and not have it checked. All of these alternatives seem a little less than totally satisfactory.

I've observed that programmers turn off warning levels in compilers because they don't want to see all those error messages. This in itself is a source of missed opportunities to detect bugs, and CodeWizard for Java will suffer some of this same effect.

What Is It Good For?
CodeWizard for Java gives you a handy tool for checking your source code as you write. If you're a beginning programmer, it may give you a leg up in learning Java (or, at least, learning some of the things you shouldn't do). This approach fits well with CodeWizard's graphical interface. And, if you're the kind of person who thinks the lint preprocessor for C is a good thing, you'll be sold on CodeWizard for Java from the beginning.

My take on it is a little different, though. While the graphical mode for beginning programmers is a nice option, I think the way to get value out of this tool is to plan to customize the rule base to reflect what you want to see happening in your own shop, and the idiosyncrasies of your own compiler, and to run the tool as part of your periodic build process. With this approach, you can treat the CodeWizard for Java output much like compiler warnings, and decide who has responsibility for taking action in response to these messages and under what conditions action is required. Be aware, though, that the APIs for doing this are pricey, so it might make sense to get a quote for the customization first.

I should note that having items 18-26 driven by user-defined regular expressions takes care of many of the normal standards' issues found in most shops, which generally have to do with naming conventions. CodeWizard does not deal with the other common shop standard issue, formatting of source code, but that is easily taken care of by a customized version of indent or a similar inexpensive pretty-printer solution. So, the tool as it exists, once you write the regular expressions, may do enough for you to make the $12,000 API less than economically worthwhile.

However, under the philosophy of using the tool for more than just off-the-shelf rule checking, it might make sense to also consider jtest!, another ParaSoft tool. jtest! is an automated testing tool that runs Java code and reports back all the errors it finds in a log file. It calculates test coverage and includes a playback facility to play back test sequences that generate errors. So, the best solution might be to combine the two within the context of controlled periodic builds, using CodeWizard for Java to enforce your shop's programming standards and try to limit some questionable programming practices, coupled with jtest! to identify actual bugs in the code.

Who Ya Gonna Call?
Statistics concerning average defect or bug rates and costs of finding and fixing bugs are not well developed in our industry, but it seems clear that the cost of finding and fixing a single bug can certainly exceed the $750 purchase price of CodeWizard for Java. If your development organization includes anything other than highly experienced Java developers (a somewhat oxymoronic term) and if you care about being able to gently enforce shop standards through an automated tool, CodeWizard for Java seems like a good deal.

Tom Bragg is a software developer and expert witness in computer litigation, from McLean, VA. He can be contacted at 202.928.1194 or by email at [email protected].