Hi Bob.

Yes, I'm aware of this feature, I've used it in Visual Works.
For this to be useful, it's really important to make sure that when you
make the decision to break a Smalllint rule, it should stay attached to
the code. This was something of a problem with the original
implementation of the RB, because the IgnoreSets were objects separate
from the code, and thus tended to drift away. They didn't get filed out
with the code, for example.

Greg H., a VA Smalltalker presented at ESUG and said (among things) he
had working code that makes Smalllint recognize stylized comments as
ignore directives. This is on VA, but he said he would extract the code
so it could be ported. It is for this that I'm waiting.

If the ignores are embedded in the code, they should be much more useful
in practice, because however you get the code, you're pretty sure to get
the ignoresets too.
The down side is of course that they're in the code, taking space, but
assuming the directives stay short and to the point, it seems a small
price to pay.

Daniel Vainsencher

Bob Hartwig <bob at bobjectsinc.com> wrote:
> Daniel,
> 
> Sorry to take a while to respond to this, I just got back from a 2-week
> vacation.
> 
> >
> >One enhancement that I know of, and I'll integrate as soon as I'm told
> >it's ready, is a better mechanism to tell Smalllint to ignore
> >"infractions" (using comments in the code).
> >
> 
> The VW and VA versions of the RB use filters for this.  Since there may be
> legitimate reasons to break a Smalllint rule, especially the Possible Bugs
> and Intention Revealing rules, you can specify for specific methods and/or
> classes to be excluded from the processing of specific rules.  This greatly
> increases the signal-to-noise ratio of Smalllint results.  
> 
> It would be nice to have the Squeak RB environment browsers hook into this
> filter mechanism.
> 
> 	-Bob