Introduction
I like to name things. A lot. And I appreciate unambiguity like a compiler. In some of my previous jobs, both as an employe...
For further actions, you may consider blocking this person and/or reporting abuse
I like this very much and we have applied these rules since long ago.
However, the rule 0 says "..., where the paramenter name tells you what object you should pass..." and the extra n in parameter is disturbing when talking about names ;-)
Besides that, although I adhere to the rule of article + (existing) class name because we adopted that in the team, I would personally prefer using nouns indicating the role of the parameter. Smalltalk is not typed, why should we declare the types of the parameters? Specially when the type is not interesting, like aString or aPoint and telling the use of the parameter is more relevant.
I share the jealousy in removing improper levels of ambiguity and vagueness in naming things. Specially because I'm conscious that it might induce a reader engineer in the future to make a mistaken assumption and these things have costs (time or worst).
And I think is worth noticing that the prefix
a/andenotes a reference to being an instance (of some class) so in your example foraSelector, theaSymbolalternative removes nurturing the intuition of the reader suggesting why it exists and forcing him to reverse engineer whileselectoron the other hand would preserve meaning.So it depends on how much the author cares about communicating meaning and nurturing the imagination of the next developer reading that code whenever that happens.
To conclude on this though, a couple of ideas I can reflect on:
What you value most, correctness or revealing intention?
Aren't compilers supposed to do their job and help on enabling/enforcing correctness so human engineers can communicate themselves on a higher more meaningful level between them across time?
What code you (and future-you) will prefer to read 10 years from now to maintain or add a feature to?
I value revealing intention,
aSelectorsuggests an instance of Selector, and there is no such thing in the image (unless you happen to have a Selector class). So, I adhere to Rule 1 as much as possible.There is related rule violation for "conversion" methods, which is to call a method
asSelectorwhen there is noSelectorclass either, but that will be subject of another post.