A Case Study on Type Hints in Method Argument Names in Pharo Smalltalk Projects — Boris Spasojevic

Pharo has a nice convention where arguments should be named as their types:

2016-03-16 16.21.16

Boris says this is a wonderful idea “please do it!” Not only is it good for readability, but also some IDEs depend on this for features like autocompletion.

So, do people actually do this ‘in the wild’? Boris studied about 150,000 arguments and found that 36% does do it but 64% did not. That sounds like a lot of fails. He studied the results a bit deeper and found that some types were treated differently.

Duck duck

For example, people would not write aClosure, but rather aBlock or they would not write aByteString, but rather aSmallString. More interesting cases even would be combinations: aDateorNumberorString. A ducktype argument name! Or even (real life example)

ASelectororElementorjQueryorBooleanorNumber

If these types were treated as correct, they got to about 50% of successful argument names.

Are devs lying?

Yes, sometimes. Boris studied 300 manually and compared the arguments to the runtime types. and 76% matched and 24% did not! Were they lying, well, no. There were small differencem likt aBrowser for aGMLBrowswer. So the developer knew what he was expecting, they were just too lazy to type the whole thing. Or sometimes, an argument was called aBlock (=a closure) but the type would be the output of running the closure.

Nice work! There also is a preprint.