Smalltalk › Cincom › VisualWorks

Selectively ignoring Smalllint/CodeCritic checks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Randy Coulman

Selectively ignoring Smalllint/CodeCritic checks

Has anyone implemented a way to tell Smalllint to ignore a method or class for a particular rule in a programmatic way? We're starting to run some of the CodeCritic checks as part of our automated test suite, and some of the rules that we're interested in have false positives that we'd like to filter out (like every TestCase subclass and test method showing up as unreferenced).

There are a couple of menu options that show up when browsing CodeCritic results that let you add class or method filters, and those do approximately what I'm looking for. However, those filters are only local to your image (unless you save them out to a file and load them in a new image). I'd prefer to have them come along with my code.

I've been thinking of trying to find a way to do this using pragmas, but before I go down that road, I'm wondering if anyone else has done something like this already.

One of the issues with a pragma approach is how to identify the rules with a literal of some sort. The filter rules only have a name, which is a (potentially translated) string, and so doesn't seem like a reliable identifier. The current filters are based on that name identifier as well.

Thanks,

Randy
--
Randy Coulman
[hidden email]

Twitter: @randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: Selectively ignoring Smalllint/CodeCritic checks

On 2/8/2012 1:18 AM, Randy Coulman wrote:

Has anyone implemented a way to tell Smalllint to ignore a method or class for a particular rule in a programmatic way? We're starting to run some of the CodeCritic checks as part of our automated test suite, and some of the rules that we're interested in have false positives that we'd like to filter out (like every TestCase subclass and test method showing up as unreferenced).

We do static tests at Soops.
We have them all sitting on a single TestCase, test methods will walk the code structure directly or call SmallLint (or other tools like prerequisite analysis, 'stupid comment' finders etc etc).
We do not direct SmallLint to skip code 1) , rather we filter out false positives from the SmalLint results afterwards.

Removal of false positives is guided by various markers like pragmas on methods, marker methods on classes, exception collections in the testcase itself.

Typical examples of such pragmas are:

<thisClassRegistersItself>
<thisMethodMayHaveNoSenders>
<LiteralBindingReferencesThatAreAllowedToBeUnbound: #( #{Foo} #{Bar} )>
<sendsUnimplementedMessages: #(#foo #bar)>

One of the issues with a pragma approach is how to identify the rules with a literal of some sort. The filter rules only have a name, which is a (potentially translated) string, and so doesn't seem like a reliable identifier. The current filters are based on that name identifier as well.

Don't use SmallLint as your model, that is too restrictive -> so don't tie pragma names to SmallLint names.

If you are working in a team it will also help to do automated blame assignment, if we see 'other developers spam' after every build we will start ignoring it entirely after three builds or so.

Here are several of test we run, notice that only a few involve SmallLint:

testAllErrorNumbersAreUnique
testAllGeneratedMethodsHaveASpec
testAllPackagesAreSufficientlyBlessed
testAllPragmasAreKnown
testAllSoopsPackagesHaveSufficientPrerequisitesForCleanLoad
testAllSoopsPundlesAreNotForkedVersions
testAllSoopsPundlesAreUnmodified
testAllSoopsPundlesExplicitelyHaveStorePrerequisites
testAllSoopsPundlesHaveEqualDevelopmentAndDeploymentPrereqs
testForAmbiguousReferences
testForIllegalMethodOverrides
testForLoadErrorsInTranscript
testForObsoletePackages
testForSendersOfBadDevelopmentMessages
testForSendersOfBadTimeConversions
testForSendersOfDevelopmentHints
testForSendersOfDevelopmentMessages
testForSendersOfIllegalDevelopmentMessages
testForSmallLintBugs
testForUnmergedReplicatedPundles
testImplementersOfPopulateForObjectValidatorOnlyDoOneDispatch
testNoNewerUnforkedSoopsPackagesAreAvailable
testNoSoopsPackagesHaveOverridesUnlessItIsFromAPatchesPackage
testNoSoopsPackagesReferenceOldStoreClasses
testNoSoopsProcessesAreRunning
testNullPackageIsEmpty
testSoopsPackagesUseCorrectWidgetIDs
testSoopsPackagesUseMenuIDsInMenuPragmaMethods
testSoopsPackagesUseMenuIDsInResourceMethods
testSoopsPackagesUseUserMessageInColumns
testSoopsPackagesUseUserMessageInLabels
testSoopsPundlesIndicatingVwVersionMatchVwVersion
testThatIsNotATestButHoldsOnlySendersToSomePopularMethodsWithoutSenders
testUndeclaredIsEmptyEnough

1) We run SmallLint only on 'our' packages, more precisely: we implemented a heuristic #isSoopsCode on CodeComponent and direct SmallLint to consider code in those packages only. Furthermore we do not run SmallLint on Soops packages that are merely patches to the system.

HTH!

--
Untitled Document

Reinout Heeck, Sr. Software Engineer

Soops - Specialists in Object Technology

Tel : +31 (0) 20 6222844
Fax : +31 (0) 20 6360827
Web: www.soops.nl

* Please consider the environment before printing this e-mail *

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n). Gebruik door anderen is niet toegestaan. Indien u niet de geadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368. Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.

This e-mail message is intended to be exclusively for the addressee. If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368. Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Randy Coulman

Re: Selectively ignoring Smalllint/CodeCritic checks

Reinout,

We're doing something similar, where we have a number of static tests not tied to Smalllint. So far, we haven't had a need to mark methods or classes to ignore those tests. It's only with the Smalllint-based tests that the issue has come up.

Do you mark individual methods, or do you have a way to place one pragma that affects an entire class hierarchy? For example, I'd hate to have to mark thousands of individual test methods as <thisMethodMayHaveNoSenders>.

The idea of filtering the Smalllint results after the fact is interesting. I assume that only affects your test suite, and not running Smalllint from the CodeCritic tab manually. Do I assume correctly?

Thanks,

Randy

On Wed, Feb 8, 2012 at 4:40 AM, Reinout Heeck <[hidden email]> wrote:

On 2/8/2012 1:18 AM, Randy Coulman wrote:
Has anyone implemented a way to tell Smalllint to ignore a method or class for a particular rule in a programmatic way? We're starting to run some of the CodeCritic checks as part of our automated test suite, and some of the rules that we're interested in have false positives that we'd like to filter out (like every TestCase subclass and test method showing up as unreferenced).

We do static tests at Soops.
We have them all sitting on a single TestCase, test methods will walk the code structure directly or call SmallLint (or other tools like prerequisite analysis, 'stupid comment' finders etc etc).
We do not direct SmallLint to skip code 1) , rather we filter out false positives from the SmalLint results afterwards.

Removal of false positives is guided by various markers like pragmas on methods, marker methods on classes, exception collections in the testcase itself.

Typical examples of such pragmas are:

<thisClassRegistersItself>
<thisMethodMayHaveNoSenders>
<LiteralBindingReferencesThatAreAllowedToBeUnbound: #( #{Foo} #{Bar} )>
<sendsUnimplementedMessages: #(#foo #bar)>

One of the issues with a pragma approach is how to identify the rules with a literal of some sort. The filter rules only have a name, which is a (potentially translated) string, and so doesn't seem like a reliable identifier. The current filters are based on that name identifier as well.

Don't use SmallLint as your model, that is too restrictive -> so don't tie pragma names to SmallLint names.

If you are working in a team it will also help to do automated blame assignment, if we see 'other developers spam' after every build we will start ignoring it entirely after three builds or so.

Here are several of test we run, notice that only a few involve SmallLint:

testAllErrorNumbersAreUnique
testAllGeneratedMethodsHaveASpec
testAllPackagesAreSufficientlyBlessed
testAllPragmasAreKnown
testAllSoopsPackagesHaveSufficientPrerequisitesForCleanLoad
testAllSoopsPundlesAreNotForkedVersions
testAllSoopsPundlesAreUnmodified
testAllSoopsPundlesExplicitelyHaveStorePrerequisites
testAllSoopsPundlesHaveEqualDevelopmentAndDeploymentPrereqs
testForAmbiguousReferences
testForIllegalMethodOverrides
testForLoadErrorsInTranscript
testForObsoletePackages
testForSendersOfBadDevelopmentMessages
testForSendersOfBadTimeConversions
testForSendersOfDevelopmentHints
testForSendersOfDevelopmentMessages
testForSendersOfIllegalDevelopmentMessages
testForSmallLintBugs
testForUnmergedReplicatedPundles
testImplementersOfPopulateForObjectValidatorOnlyDoOneDispatch
testNoNewerUnforkedSoopsPackagesAreAvailable
testNoSoopsPackagesHaveOverridesUnlessItIsFromAPatchesPackage
testNoSoopsPackagesReferenceOldStoreClasses
testNoSoopsProcessesAreRunning
testNullPackageIsEmpty
testSoopsPackagesUseCorrectWidgetIDs
testSoopsPackagesUseMenuIDsInMenuPragmaMethods
testSoopsPackagesUseMenuIDsInResourceMethods
testSoopsPackagesUseUserMessageInColumns
testSoopsPackagesUseUserMessageInLabels
testSoopsPundlesIndicatingVwVersionMatchVwVersion
testThatIsNotATestButHoldsOnlySendersToSomePopularMethodsWithoutSenders
testUndeclaredIsEmptyEnough

1) We run SmallLint only on 'our' packages, more precisely: we implemented a heuristic #isSoopsCode on CodeComponent and direct SmallLint to consider code in those packages only. Furthermore we do not run SmallLint on Soops packages that are merely patches to the system.

HTH!

--

Reinout Heeck, Sr. Software Engineer

Soops - Specialists in Object Technology

Tel : <a href="tel:%2B31%20%280%29%2020%206222844" value="+31206222844" target="_blank">+31 (0) 20 6222844
Fax : <a href="tel:%2B31%20%280%29%2020%206360827" value="+31206360827" target="_blank">+31 (0) 20 6360827
Web: www.soops.nl

* Please consider the environment before printing this e-mail *

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n). Gebruik door anderen is niet toegestaan. Indien u niet de geadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368. Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.

This e-mail message is intended to be exclusively for the addressee. If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368. Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Randy Coulman
[hidden email]

Twitter: @randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc