+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 >