Hi, I uploaded to Squeak Map a package to deal with the SmallLint failures. The package name is: Small Lint Failure http://map.squeak.org/accountbyid/ce6957eb-c5ff-4a6e-a575-a1467238905e/package/25c17dc0-bf31-4215-8ba9-bf0df8157449 The idea of this module is to declare smalllint failures as expected, so when SmallLint is run again, the expected failures will not appear. For example, let's say that there is a long method in ClassA>>method1. If SmallLint is ran, it will detect that error (long method) and it will report it. But suppose that the method, for some reason, can not be refactored in smaller ones... the next time SmallLint is run, it will report the same error even though you know it is not. The problem with this behavior is that the programmer gets tired of this "expected" smalllint failures and he will stop running SmallLint because of that.... SmallLint it is not prepared to be run continuously, in an automatic process because this expected failures will pop up. This module let's the programmer declare this expected failures so they are not reported when SmallLint is run. To declare this "expected" long method failure, it is very simple as it is shown below:

ClassA class>>expectedSmallLintFailures "Each class that has expected SmallLint failures has to declared this method which returns a collection of expected failures"

^Array with: (ExpectedSmallLintFailure longMethodsFailedClass: self failedMethod: 'method1' asSymbol reasonDescription: 'The method can not be refactored in smaller ones' definedBy: 'Hernan')

As you can see in the example, an ExpectedSmallLintFailure is created for the longMethods failure. The failure is for ClassA (self), the failedMethod: is #method1 (see that I wrote 'method1' asSymbol because I don't want to have references to #method1 because SmallLint will treat it as a sender when it is not), the reason because it is declare as expected is that the method can not be refactored and Hernan (me) declared it. This module helps the programmer to treat this smalllint failures, but it also allows the programmer to document the reason of the failure. For each smallLint failure, there is a message to create it in the class ExpectedSmallLintFailure. The module has a test for each failure so you can see how it works also.

To be able to run it from the refactoring browser, the following methods have to be changed: RefactoringBrowser>>addClassSubMenuTo: aMenu "Added to to support the small lint failure model" lintSubMenu addLine; add: 'expected failures on class...' translated action: #expectedSmallLintOnClass; add: 'expected failures on class category...' translated action: #expectedSmallLintOnClassCategory; add: 'expected failures on class hierarchy...' translated action: #expectedSmallLintOnClassHierarchy. pkg ifNotNil: [lintSubMenu add: 'expected failures on package...' translated action: #expectedSmallLintOnPackageWithClassCategory]. "End of small lint failure model support"

RefactoringBrowser>>systemCategoryMenu: aMenu "Added to integrate the browser with the small lint failures model - Hernan" lintSubMenu addLine; add: 'expected failures on class category...' translated action: #expectedSmallLintOnClassCategory; add: 'expected failures on package...' translated action: #expectedSmallLintOnPackageWithClassCategory. "End of addition"

Well, I hope you will enjoy it!. We use it at work in our integration process and it is very helpful. We don't do it with all the modules, but with those we mark as "stable". Having no smalllint failure give us a lot of confidence in our code, like the unit test do.

Hernan.