TITLE: Patterns for Naming Things
AUTHOR: Eugene Wallingford
DATE: May 13, 2011  2:26 PM
DESC: 
-----
BODY:
J.B. Rainsberger's
<A HREF="http://blog.thecodewhisperer.com/post/4609737669/long-names-a-smell-or-a-clue">
   short entry</A>
grabbed my attention immediately.  I think that Rainsberger
is talking about a pair of complementary patterns that all
developers learn at some point or other as they write more
and bigger programs.  He elegantly captures the key ideas
in only a few words.

These patterns balance common forces between giving things
long names and giving things short names.  A long name can
convey more information, but a short name is easier to
type, format, and read.  A long name can be a code smell
that indicates a missing abstraction, but a short name can
be a code smell that indicates premature generalization,
a strange kind of YAGNI violation.

The patterns differ in the contexts in which they appear
successfully.  Long names are most useful the first time
or two you implement an idea.  At that point, there are
few or no other examples of the idea in our code, so there
is not yet a need for an abstraction.  A long name can
convey valuable information about the idea.  As an idea
appears more often, two or more long names will begin to
overlap, which is a form of duplication.  We are now ready
to factor out the abstraction common to them.  Now the
abstraction conveys some or all of the information and
short names become more valuable.

I need to incorporate these into any elementary pattern
language I document, as well as in the foundation patterns
layer of any professional pattern language.  One thing I
would like to think more about is how these patterns
relate to Kent Beck's patterns <EM>Intention-Revealing
Name</EM> and <EM>Type-Revealing Name</EM>.
-----