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