I generally go for intention revealing (e.g. fullName) because the class of the parameter can change arbitrarily. e.g. your aString might become a Name object that can answer something useful when you know just the first or family name. But I also mostly write code for my own consumption.
If there is anything recommended/specified in https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X I'd use it in training materials. I'm away from the house but can look in my copy later if no one else chimes in with a better answer. It also seems like a "how much milk do you like in your coffee?" choice where the tradeoffs between one vs the other isn't high and the code in action will let you know whether you've got it right. 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? > > 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
