The Smalllint tool checks for over 60 common types of bugs. Some of these are from the classic bug list. When it suspects a bug, it opens a Refactoring Browser on the classes or methods in question.
To use the Smalllint tool, evaluate "Smalllint open, select the button from the launcher, or select the "Smalllint" option under the ENVY menu. This should open a window:
To evaluate a check, you need to select rule to run and also which classes to check. The rule is selected by the drop down menu at the top left of the window (or from the "Rules" menu in IBM ST), and the classes are selected from the bottom lists. Once you highlight an items such as a class, you need to select add from its pop-up menu. This will cause a checkmark to appear by the item. Only items with checkmarks by their name will be checked by the program. Once you have selected both the rule and classes, you are ready to run the check. After the program finishes checking your code it will either open a browser on the classes or methods that failed its check or open a dialog that says that it didn't detect any problems. At any time while the check is running you can abort the process by hitting the abort button.
The "Result" button opens results already computed from a "Run" without re-running the check. This is useful, for those times when you accidentally closed the results window. Also, the "Empty cache" button will flush the current cache so that new changes will be reflected to the rules.
A description of all the different rules can be found on this page.
This section lists the known bugs and their work arounds (if they exist). If you know of a bug that is not listed in this section, please mail us. If we know of the bug, we might fix it, but we can't fix bugs that we don't know about.
Many times the tool will select the wrong item when displaying the results. Since each rule only has a list of strings it looks for, it will often find a string that is incorrect for this method, but correct for another method. This occurs frequently when running the temporary variable read before written. Since such variables often have short names such as "i", the browser will select any "i" in the method whether or not the method even has an "i" defined as a temporary variable. To help this problem, you might want to rerun the check only on the class that has the problem. This way you will not get the other search strings from methods in other classes.
Instead of using menu buttons to select the rules, the IBM Smalltalk version uses pop-up menus on the labels. We have added the pop-up menu to the menu bar, but there are problem when swapping the menus (in the SmalllintResultEditor) so that code has been commented-out. If an IBM Smalltalk expert would like to look at the code, we would be happy to accept any fixes.
For some rules, Smalllint might return false positives. This is mainly due to methods that have the same name but are used in different ways. For example, a common false positive happens with the "Uses do: instead of collect: or select:" rule in that it will detect creating menus using a MenuBuilder, since MenuBuilder's also understand add:. As with other automated tools, everything returned by Smalllint is not necessary a problem, but they are areas that you might want to look at further.
This check may incorrectly report a temporary read before written, if the temporary is defined both as a temporary and a block variable in the same method.
Sometimes the tool will appear to pause before executing a check. This is due to the tool filling the cache. Once the cache is filled the check proceeds normally.
You can generate exceptions by browsing code while the lint tool is running. Also, it may cause rules to return methods that did not fail. Smalllint only runs in the background so that you can easily abort the process. Under VisualWorks these race conditions do not appear, and it is alright to browse code while Smalllint is running.
Comments or suggestions can be sent to
Last updated on 29-Apr-97.