Having refreshed my memory by rereading that section of the style book - I see the source of my discomfort... I don’t find the guidelines on parameters very strong - and I think (like others) I side more with guideline 25 most of the time where it’s sensible (not just for multiple similar parameters).
Thus my preference seems to be for semantic typed naming eg: fullNameString, sourceCollection, ageNumber (this one feels weird though), indexingInteger I’m still a little unsure by using a/an as a prefix when doing semantic typed naming - I think the style book is suggesting that prefix is for typed names (exclusively?). I think the risk of collision with inst var names is low (and guideline 9 and it’s introduction seem to favour semantic naming for inst vars anyway) but I do recall once seeing someone use a prefix “my” on all inst vars. That was kind of cute, and seemed to read ok - and sort of encouraged you to add the setter/getter (without my) when needed. But maybe safer to avoid that convention I’m guessing? Tim Sent from my iPhone > On 12 Jul 2018, at 12:27, Tim Mackinnon <tim@testit.works> wrote: > > Sounds like what I’ve been doing is what others do too - I just wasn’t sure > if my memory had served me well. It was great to be reminded about some of > the subtleties though - hadn’t thought about a/an stopping inst var > collisions. > > I actually have an original copy of that style book, I was working at OTI at > the time and knew Suzanne and Dave and we were all given a copy (probably > worth a quick skim again) > > Thanks everyone > > Tim > > Sent from my iPhone > >> On 12 Jul 2018, at 11:09, Erik Stel <erik.s...@gmail.com> wrote: >> >> In the day, I learned from Smalltalk with Style: >> http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf >> >> On PDF-page 13 naming starts. On PDF-page 29 parameter names are explained >> (but refers back to typed names for example). Naming ends at PDF-page 35. So >> quite elaborate explanation of naming ;-). >> >> In practice I also mix typed names (aCollection), semantic names (addresses) >> and a combination (anAddressCollection). I prefer the combination except for >> trivial situations or when the (class and) method name provide(s) enough >> context (name: aString). This later might in itself be less trivial if the >> context get broader than class and method (name). >> >> @Tim, the book might be useful for more than just naming since it covers >> quite some ground. >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >
