The primary trade-off is between Type Suggesting vs. Role Suggesting parameter names. For example, aString and aSymbol tell us only what type of object the parameter expects, while aName and aTitle tell us the *role* (or purpose) of the parameter, with the expected type hopefully obvious. You can combine the two, like aNameString, or aTitleSymbol, and this should be done where necessary to prevent confusion. For example, in XMLParser I have a URI class, XMLURI, and to avoid confusion over parameters that accept both XMLURIs and URI strings, I use anXMLURIOrURIString. Using "a" and "an" prefixes is always a good idea, because it prevents collisions with instance variables, allows you to tell at a glance that an identifier is a parameter and not an inst var, and it produces more natural, readable message signatures, like "copyFrom: anOldPath to: aNewPath".
Sent: Wednesday, July 11, 2018 at 6:24 PM From: "Tim Mackinnon" <tim@testit.works> To: "Pharo Users Newsgroup" <pharo-users@lists.pharo.org> Subject: [Pharo-users] Naming parameters - conventions?
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
___ montyos.wordpress.com