At 01:12 PM 2/1/99 -0800, Jerome Garcia wrote:
>On Mon, 1 Feb 1999, Dan Ingalls wrote:
>     
>> The lines of code thing is just plain confusing.  Generally less is 
>> better, and I just don't think you cn compare systems this way.  
>> Consider...
>> 
>>       | strm |
>>       strm := WriteStream new on: (String new: 10).
>>       tempNames do: [:n | strm nextPutAll: n; space]. 
>>       tempStr := strm contents.
>> versus...
>>       tempStr := String streamContents:
>>           [:strm | tempNames do: [:n | strm nextPutAll: n; space]]. 
>> 
>     These lines of code and Jake Hamby's response remind me of the many 
>     times over the past thirty years when I was learning an new language 
>     or environment and wished that I could put the development tool in 
>     "nag" mode. When I wrote the first set, it would say "Nonsense. That 
>     is crummy code. Do it like this...". Sort of like a grammer checker. 
>     Of course, I would like to be able to tell it where to go if I didn't 
>     agree :-)
>     
>     Much of the poor code I seen has been the result of someone working 
>     under a tight deadline, remembering how they did something in a 
>     previous language, and doing it the same way because they did not have 
>     time to discover how to do it correctly. I may be naive in thinking 
>     that it should be possible for a development environment to give 
>     active guidance but I would still like to see it happen. Does anyone 
>     happen to have a good guess as to in what percentage of code snippets 
>     such as the above it would be possible to programmatically recognize 
>     that the first is equivalent to the second and recomend the second?

A good percentage of the code could be recognized. There would probably be
3-4 common ways of doing it that would catch 95% of all cases. The
Smalllint tool from the Refactoring Browser doesn't catch the case above
(since #streamContents: doesn't exist in VA or VW), but it catches many
other ones: using do: instead of #collect: or #select:, using #whileTrue:
instead of #to:do:, using #ifTrue:ifFalse: instead of #min: or #max:, etc.
Overall, there are over 60 different checks that Smalllint performs and
many of them are the "grammar" type checks as above. The complete list of
checks is at:
    http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/LintChecks.html

Adding new checks to Smalllint is relatively easy. Many times it just
requires writing some pseudo Smalltalk that matches some real Smalltalk
code. For example, one of the pseudo Smalltalk code snippets for detecting
when someone is using a whileTrue: instead of to:do: is:
	| `@temps |
	`@.Statements1.
	[`index <= `@stop]
		whileTrue: 
			[| `@BlockTemps |
			`@.BlockStatements.
			`index := `index + 1].
	`@.Statements2
There are three other possibilities that it uses for the rule.

As far as the usefulness of such a system; I find Smalllint very useful.
Even though I've been working in Smalltalk for several years now, I still
write stupid code (although less frequently :)). The biggest problem with
these "grammar" checkers is that as you become better the hit-to-miss ratio
gets too low and most people stop using them. 


John Brant