+100

/————————————————————/
Encrypted email at jgpfers...@protonmail.com
Web: www.objectnets.net and www.objectnets.org

> On Jul 11, 2018, at 18:20, Richard Sargent 
> <richard.sarg...@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
> 

Reply via email to