Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!dhoag
From: dhoag@netcom.com (David Hoag)
Subject: Re: Question:  variable naming convention to suggest object "type" ?
Message-ID: <dhoagD3or1o.BG0@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <3gv7sk$ibs@lace.Colorado.EDU> <3h4hd0$o42@isnews.is.s.u-tokyo.ac.jp>
Date: Wed, 8 Feb 1995 14:32:11 GMT
Lines: 56

Jeff McAffer (jeff@is.s.u-tokyo.ac.jp) wrote:


: In article <3gv7sk$ibs@lace.Colorado.EDU> gmecchia@cc.colorado.edu writes:

:  >It is sometimes suggested that variable names somehow suggest or
:  >indicate the type of the value that the variable is holding, names such
:  >as aString, aNumber, aCustomerString, fruitInt, fruitString
:  >so that the code documents itself in helping the programmer understand
:  >what kind of values are assigned to the variable.  I even saw names 

: IMHO, names should be semantic not type-based.  As you say, type-based
: names conflict witht he idea of polymorphism.  To borrow from another
: thread I was just reading, if the name "aDuck" means that the value
: should be an instance of Duck then how does that account for Geese,
: which, in a restricted sense can be used in place of Ducks?  Smalltalk
: does not have types so what significance am I to draw from the fact
: that Goose may or may not be a sub/superclass of Duck?  If an arg is
: "aDuck" is it ok to use a Goose?  Who's to say?  

One of the biggest benefits of OO technology, and particularly 
Smalltalk, are the maintainence savings.  Using a parameter like aDuck 
may not let me know if aGoose is a valid parameter or not, but I do know 
that when the original author wrote the method he had ducks in mind.  
Everything a programmer can do to assist another in reading his code is a 
valuable effort.

: Furthermore, attempts to document acceptable parameter types via the
: parameter name fail in the face of multiple disjoint acceptable
: parameter values.  For example, what if the arg can be nil, true,
: false, or some String?  I guess nilOrBooleanOrString.  Barf.

I would never suggest that using aXXX is the answer to all methods.  The 
example you gave is an excellent example of one that may not fit the 
naming convention and a different parameter name should be used.  The 
parameter name should convey meaning about that parameter.  Perhaps the 
arg you mentioned is being used by the method in question to determine 
the success of another transaction.  A potential name may be successIndicator.

: This convention seems to be a holdover from the original practice in
: ST to use aXXX names.  Personally, typing-like information should be
: in the method specification (not comment) and we should have real
: tools for doing specifications.

Until such tools arrive take advantage of the fact that parameters can be 
anything and use it as a means to document your intentions.

: JEff

: --
: ato de, |m        -- This reminds me of the time I accidently typed 
:                      'rm -r *' in my thesis subdirectory...

- Dave

Easel Corporation
