Tim Mackinnon wrote
> Hi everyone, something I’ve meant to ask over the years, as I’ve seen lots
> of variation and was taught something else in the day...
>
> What is the suggested way of naming parameters?
>
> I was taught {“a”/“an”}DataType, so it would be:
>
> #name: aString
>
> Which works ok (although falls apart if you refactor as the tools don’t
> interpret it - although I guess could be improved to do so)
>
> However often I find myself wanting to communicate a bit better as in:
>
> #name: fullNameString
>
> Which isn’t strictly a datatype (and I tend to leave out the a/an when I
> do this). But it feels a bit off piste and it does make me consider
> whether my selector is named badly and should be:
>
> #fullName: aString
>
> Which takes me back to the convention I learned long ago.
>
> This said however, we often need to match similar #on:do, #in: generic
> selector names and then it’s not always obvious the intent of parameter.
>
> Any thoughts to share?
In my opinion, worth what you pay for it, the goal is to communicate and set
the reader's expectations. You want the reader to know what kind of
behaviours the argument should provide.
So, when creating a setter method, it is sufficient to name the argument
"aString". The method selector is telling you the purpose of the string. The
argument is telling you that it is no more and no less than a string. It
isn't trying to convey that there is a structure to that string. Just that
the name is a string.
Likewise, when naming a parameter for a more complex method you may need to
say more, depending on what the selector itself says.
e.g. #blahBlahBlahWithName: can easily work with "aString".
Conversely, a method that takes multiple string arguments needs to
effectively distinguish them from each other.
e.g. #blahBlahBlahWithName:address:telephone: needs to do better than Dr.
Seuss (aString1, aString2, etc.) In this example, I tend to use e.g.
"nameString", "addressString", and "telephoneString". This conveys the
purpose of each argument and identifies the behaviours one should expect.
I am *not* a fan of argument names like "aNameString", since that can
mislead readers into expecting name-specific behaviours from the argument.
> I ask because for exercism, we should try and set a good example.
>
> Tim
>
> Sent from my iPhone
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
