SmallLint is part of the RefactoringBrowser package. It started off being a style checker, but the first several rules searched for common SmalltalkLanguage bugs, therefore, we named it SmallLint. Ironically, in recent years, we've added more style-based types of rules, but the old name stuck. (We just like typing three l's consecutively). --DonRoberts


 ''The one-l lama, he's a priest.''
 ''The two-l llama, he's a beast.''
 ''But I will bet a silk pajama,''
 ''There isn't any three-l lllama.''
    -- ''OgdenNash''

(Large fires are often referred to as "three alarmers", though...)
----
Have you had much success with the style-checker part? Was the aim to find (and fix) bad CodeSmell''''''s? I'm curious as to how objective they are. Can we say, "This code is bad" without needing to understand its deep semantics? -- DaveHarris
----
Yes, most rules relate to CodeSmell''''''s somehow. In fact many relate to the OnceAndOnlyOnce rule. There are several rules of the form: "Uses X idiom instead of the Y idiom" where the Y idiom better represents the ideas of the code. For example, you could write something like:

 i := 1.
 [i <= aCollection size]
   whileTrue: 
    [...do something with "aCollection at: i"...
    i := i + 1]

which would be better represented by:

 1 to: aCollection size do: 
  [:i | ...do something with "aCollection at: i"...]

which you could then determine is really a do:

 aCollection do: [:each | ...do something with "each"...]

For these types of checks you don't really need to understand the code. There will be sometimes when you're wrong, but it will be a lot fewer than the times you're correct. However, as you rewrite the problem code, the percentage of cases where you're wrong will increase, since the places where you're right will be removed.

One of the more interesting things about running SmallLint on new code is that many times one method will fail several checks. If I look closely at the code, not only will I find a new SmallLint rule, but I'll also find some bugs in the code. Most likely, the original developer didn't understand the problem well enough and tried to hack something into existence. --JohnBrant
----
''(Some discussion originally on OnceAndOnlyOnce:)''

[OnceAndOnlyOnce has been] used to mean "Don't put the same information in two different places".  I disagree with this meaning; sometimes redundant comments (as opposed to redundant code) are very useful.  For example, when you redefine = in VisualWorks, you should also redefine ''hash''.  I believe that both the hash and = methods have comments warning users of this; if they don't, they should.  This is a case where it pays to put the same comment in two different places. -- BetsyHanesPerry

In VisualWorks, = and ''hash'' are an implicit Interface. Unfortunately, VW lacks explicit, first-class Interfaces, so you have to distribute the warning comment across the members of the implicit interface.  Oh well. --DaveSmith

This points out another example of OnceAndOnlyOnce. The solution is to have a program that checks that any class that defines = also defines ''hash''.  In fact, SmallLint, which is part of the RefactoringBrowser, makes this check. -- RalphJohnson

----
SmallLint sounds like a Smalltalk version of the java checkstyle tool (see http://checkstyle.sourceforge.net/config_coding.html for what it checks)
The EclipseIde plugin basedon checkstyle can be configured to do the checking pretty regularly.  - StanleyKnutson

----
Since Smalllint predates the public release of the Java *language*. I would argue that the checkstyle tool is a Java version of Smalllint. :) - DonRoberts

----
CategoryLint CategorySmalltalk