 |
|
Tools
|
|
|
Refactoring Browser |
 |
|
Method Wrappers |
|
|
Sharp Smalltalk |
|
|
SmaCC |
|
|
 |
| Refactoring
Browser - Smalllint |
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.
User instructions:
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.
Bugs/Limitations:
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.
Highlighting: 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.
IBM & Smalllint:
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.
False positives:
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.
Temporaries read before
written: 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.
Pausing:
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.
Race conditions in IBM ST: 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
brant@refactory.com
and
roberts@refactory.com.
Last updated on 29-Apr-97.
|
|
 |