On Jan 22, 2013, at 7:19 AM, Jan Vrany wrote: > Hi, > > On 19/01/13 10:16, Stéphane Ducasse wrote: >> Hi jan >> >> do you have an example of such tagging? > > Look at > > RBTranslateLiteralsInMenusRule class>>tagsBasic, > RBNilOrEmptyCollectionReplaceRule, > RBMethodSourceContainsLinefeedRule, > RBTempsReadBeforeWrittenRile > RBLawOfDemeterRule > RBContainsNamespaceIdentifiersRule > > at > > http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ > > Some comment on tagging > > http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?revision=1.9&view=markup
Ok It is a good idea. What is the license of the changes you did? And sorry but we do not want to have author in comment for the moment :) > Could you please give me a pointer where newest Lint for Pharo > lives? For now it lives in Pharo20. Once we migrate for real to smalltalkHub I want to have subprojects for RB, SmallLint. We tried for while to have none disruptive changes by putting changes as extensions of code critics but it does not work for cleaning the rules. Stef > > > Cheers, Jan > > > >> Right now we are also thinking that we want three kinds of rules >> - 1 whose result is either zero because there is no problem or zero >> because we flag the false positives >> - 2 more fuzzy one where we should have flase positive defined per >> package >> - 3 more statistical rules (long methods, large number of instance >> variables) >> >> We are checking how we can find decent threshold values not generating >> thousands of warnings and >> also if we want to embed false positives for them too. May be they are just >> good for trend analysis and >> when you want to spot ugly code but you do not care to have them under your >> nose systematically. >> >> For the rules I'm also changing the implementation to make sure that we can >> customized the list of selectors, thresholds …. >> without having to recompile a method. This way people will be able to use >> their own conventions. >> >> Stef >> >> On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: >> >>> Hi Stef, >>> >>> while massaging SmallLint rules, you should also have look at >>> Smalltalk/X version of SmallLint [1] as we have ported >>> Pharo version and improved some rules. I have also added >>> a tagging system. That's useful for some rules are only >>> good if you want to ensure portable code, some are simply >>> broken and some stupid, etc. Having them properly classified >>> would help us all. >>> >>> Tell me once you finish your ride, I'll merge changes back :-) >>> >>> Jan >>> >>> [1] >>> http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ >>> >>> to checkout issue: >>> >>> cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co >>> stx/goodies/refactoryBrowser/lint/ >>> >>> >>> On 18/01/13 17:06, Stéphane Ducasse wrote: >>>> Hi >>>> >>>> While looking at SmallLint rule, I saw a rule that ensures that a given >>>> method always performs a >>>> super send. >>>> >>>> Here is the current list: >>>> >>>> ^#(#release #postCopy #preBuildWith: #postOpenWith: >>>> #noticeOfWindowClose: #initialize postBuildWith:) >>>> >>>> >>>> and I'm cleaning the list because there are VW elements such as >>>> postBuildWith: >>>> but do we have some other to add? >>>> >>>> Stef >>>> >>>> >>>> >>> >>> >> >> >> > >
