TITLE: By Any Other Name ... Not!
AUTHOR: Eugene Wallingford
DATE: August 27, 2004  2:18 PM
DESC: good names in the news and on my mind
-----
BODY:
Everyone knows that using good names in code is essential.  What more
is there to say?  Apparently, plenty.  I've encountered discussions
of good and bad names several times in the last few weeks.

Not too surprisingly, the topic of names came up during the first week
of my introductory OOP course.  I gave my students a program to read,
one that is larger than they've read in preceding courses and that
uses Java classes they've never used.  We talked about how good names
can make a program understandable even to readers who don't know the
details of how an object works.  The method names in a class such as
<TT>java.util.Hashtable</TT> are clear enough that, along with the
context in which they were used, students could understand the class
that uses them.

Often, issues that involve names are really about something bigger.
Consider these:

<UL>
<LI> Jason Marshall writes about a design anti-pattern that he calls
     <A HREF="http://jroller.com/page/jdmarshall/20040530#what_s_in_a_name">
        Implied Structure</A>.
     Sometimes, developers need to create an object with a descriptive
     name in order to communicate knowledge they possess but that their
     program doesn't express.  The new object, even if it is light on
     behavior, captures a valuable domain abstraction.  The name
     communicates the abstraction to readers of the code, and it also
     allows the compiler to enforce meaningful values for variables.
<P>
<LI> Nat Pryce recently wrote about
     <A HREF="http://nat.truemesh.com/archives/000362.html">
        methods that take arguments which change the meaning of the method</A>.
     In particular, Nat is concerned with arguments that negate the
     method's meaning, such as:

     <CENTER>
     <TT>void assertButtonIsEnabled(String buttonName, boolean isEnabled)</TT>
     </CENTER>

     <P> When a client passes <TT>false</TT> as the second argument
     with this message, the result is that the button is <B>dis</B>abled.
     Such code is almost impossible to follow, because you have to pay
     attention to the guilty argument in order to get even a high-level
     understanding of the code.

     <P> Avoiding this situation is relatively easy.  Create a second
     method with a name that says what the method means:

     <CENTER>
     <TT>void assertButtonIsEnabled(String buttonName)</TT> <BR>
     <TT>void assertButtonIsDisabled(String buttonName)</TT>
     </CENTER>

     <P> Not only is Nat spot on with his analysis, but he has come
     up with a wonderfully evocative name for this anti-pattern, at
     least for those of us of a certain age: the Wayne's World Method.
     This name may be too specific in time and culture to have a long
     life, but I just love it.
<P>
<LI> Finally,
     <A HREF="http://www.oopsla.org/">
        OOPSLA 2004</A>
     has been much on my mind lately, with all my work on the
     <A HREF="http://www.oopsla.org/2004/ShowEvent.do?id=educators_symposium">
        Educators Symposium</A>.
     I always look forward to OOPSLA's invited talks and keynote addresses,
     and this year one in particular has caught my eye, Ward Cunningham's
     <A HREF="http://www.oopsla.org/2004/ShowEvent.do?id=802">
        Objects, Patterns, Wiki and XP: All Systems of Names</A>.
     I am a
     <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-07.html#e2004-07-19T10_52_37.htm">big fan</A>
     of Ward and his work.  He seems always to be in the vanguard of
     what everyone will thinking about in a few years.  According to
     the promotional buzz, Ward's talk will "unravel" his experience
     "building tools for the not quite tangible".

     <P> I'm not sure exactly what Ward will talk about, and I can't
     wait to find out.  But the title hints that he will follow the
     thread of names through several of his contributions to our
     industry.  Just think about the role names play in connecting the
     tissue of a pattern language, the fabric of ideas that is a wiki
     -- and the domain model that comprises an object-oriented program.
     And perhaps names play a more central role?  I look forward to
     Vancouver.
</UL>

Important ideas have a depth that we can explore in thousands of ways,
never quite the same.  Names are one of them.
-----