+100 /ââââââââââââââââââââ/ Encrypted email at jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org
On Jul 11, 2018, at 18:20, Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
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