> >>> "Colin Putney" 03/02/04 15:03 >>>
>
> On Feb 29, 2004, at 1:49 PM, goran.krampe at bluefish.se wrote:
>
> > Hi all!
> >
> > Dan Ingalls <Dan at SqueakLand.org> wrote:
> >> PS:  On the topic of variable names, I happen to oppose
> the "aString"
> >> style of variable naming except when you really can't think of
> >> anything better.  I feel a variable should be typed by its
> type, and
> >> named by its role (ie "boxCount" instead of "anInteger".
> >> Unfortunately we don't have a type inference system and a
> button to
> >> show the types when we want them.  Me, I'm going to keep naming by
> >> role, and encouraging work on type inference.
> >
> > I agree with this. I would only use "aString" if I couldn't come up
> > with
> > something better which is "role based". But I still think
> the general
> > pattern of "aString" is better than "string".
>
> I think Stéphane made an important point that's been overlooked. I
> hadn't thought about it before, but I now notice that I too
> differentiate between arguments to a message and temps and
> ivars. With
> temps and ivars, I always use a role based name. But for
> arguments, the
> role is given by the keyword in the selector, so I use a
> type-indicating name. This is especially useful for accessor methods,
> because the ivar will have a role-based name, and so one
> *must* choose
> a different name for the argument. Describing the same role
> differently
> is redundant, but describing the type provides more information. For
> example, I find this:
>
> name: aString
> 	name := aString
>
>
> preferable to this:
>
> name: theName
> 	name := theName

I've not got my copy of Kent's "Smalltalk Best Practice Patterns" to hand,
but I seem to recall quite strongly that Kent suggests exactly this: that
a parameter name should suggest acceptable types and a temp/ivar name should
suggest its role.

Hah, based on Google, the patterns have the following (oh, so obtuse!)
names:
* Role Suggesting Instance Variable Name;
* Role Suggesting Temporary Variable Name;
* Type Suggesting Parameter Name.

This doesn't apply to the Crochety Oldbies, but certainly for anyone new to
Smalltalk (like me) I cannot recommend this book enough. Actually, I cannot
recommend this book enough for _any_ OO programmer - I use lots of these
patterns at work writing in Delphi.

And, of course, Kent gives us pretty sane code style guidelines as well.

frank