Re: To Richard Heathfield: enough's enough

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 12/26/03 

Date: 26 Dec 2003 09:03:45 -0800

Randy Howard <randy.howard@FOOmegapathdslBAR.net> wrote in message news:<MPG.1a55d4155d78ed27989a1f@news.megapathdsl.net>...
> In article <3febf0a7@news2.power.net.uk>, invalid@address.co.uk.invalid
> says...
> [in reference to Hungarian notation]
> > It's a silly idea, partly because it makes the code hard to read (and thus
> > hard to understand) and partly because it nails the name to the type. If
> > you have to change the type, you either have the maintenance headache of
> > changing every occurrence of the name, or you leave the name misleadingly
> > indicating the old type.
>
> Perhaps another source might be something he would at least consider. The
> following is not specific to C, but provides some interesting insights.
> Microsoft actually recommends against it, as highlighted below.
>
> Excerpts from
> http://www.aspalliance.com/articleViewer.aspx?aId=74&pId=-1 :
>
> Cons:
>
> If you change an identifier?s type, you must change the identifier itself
> and all references to it.

This -> . <- is the world's smallest violin. Actually, when you use
Hungarian notation, the identifiers are easier than non-Hungarian
notation to grep, while remaining easy to grok.
>
> It obfuscates code from being read like text and thrusts this property of
> the object forward even if you didn't care about it as the reader.

If you don't care about it why are you reading the code?

I find the phrase "I don't care about x" in a technical context
EXTREMELY disturbing to the extent it replaces a responsible
separation of concerns with irresponsibility, which remains
irresponsibility even when sanctified by a corporation.

>
> Puts an emphasis on the type instead of the descriptive identifier name
> encourages poor variable names
>
No, the SAME conscientiousness that uses Hungarian notation in the
first place is also willing to use meaningful names such as intIndex
and strInstring.

 
> It is a human-maintained convention that can be erroneous, thereby
> misleading code readers even more than they might have been if it weren?t
> there.
>
I agree that it poses the possibility that you might discover that
intIndex is a Long: but this is the tragic, human condition in which
man finds himself battling an absurd universe. However, as Sartre
shows in l'Etre et Neant, choice makes meaning where none existed
before, and in fact the error simply presents the developer/maintainer
with a tragic choice, and that is to correct the damn identifier to
lngIndex.
 
> Should you check every notational assertion with its declaration anyway?
> If so, then what is the point of this notation?

It is holistic, for if the notation is followed consistently, the
check can be by exception.

>
> There are too many different types to create meaningful, unique
> abbreviations for, particularly in an object-oriented system.

This is true, which is why all value types do indeed have a meaningful
prefix, to wit and in ascending order of containment: boo (or bln),
byt, shr (sht is tempting but problematic), int, lng, sgl, dbl, str.
Popular and rugged Marlboro man type reference objects, objects with a
past, such as Collections should have a prefix like col as should
Windows forms objects such as lbl.

Beyond this obj is fine.

>
> Abbreviation systems vary from company to company and even from person
> to person.

Oh that's terrible.

What's missing here, completely missing, is the tolerant idea that (1)
a good program is the single product of a single mind or cohesive
team, neither subject in any way to management whims and (2) meaning
does NOT reside in words.

By (2) I mean de Saussure's 1916 discovery in A Course of General
Linguistics. It is that the meaning of a language unit is not in some
mystical correspondence to reality, something that ultimately has to
be maintained by a a hypostatized Cartesian deity, but in the
differences between symbols and the nameless structure so generated.

The wrong belief generates the pernicious view that "water" and not
"agua" is the proper name for H2O and various forms of language
racisms.

I'd say that if one system is followed consistently in a single run
unit, this is 99% better than program texts which represent
battlegrounds between different naming systems.

But assuming that this is true, we then can see that Hungarian
notation, used consistently, adds value to a pre-existing consistent
structure. A program with consistent Hungarian is better than a
consistent text without Hungarian because it is more communicative and
more informative.

To then say, but each one of the prefixes MIGHT represent a point of
failure (such that intIndex is declared as a Long) is nonsense which
could be applied to getting out of bed in the morning.

>
> Never applied consistently, even by Microsoft.
>
> Reasons Why Not to Use Hungarian Notation
> -----------------------------------------
>
> You can often tell an identifier?s type by the usage. This is particularly
> true in OO environments where you often set an identifier to a new
> followed by the type or when a method tells you what type it returns

In many other cases, "you can't tell a book by looking at de cover".
>
> Microsoft recommends against it
> -------------------------------

Oh my. Lions, tigers, bears and Steve Ballmer.
>
> From Microsoft?s guidelines for field names:
>
> Do not use Hungarian notation for field names. Good names describe
> semantics, not type.
>
Good names describe semantics ONLY within a discourse community and
there are in programming different discourse communities.

Within C trolldom, the denizens snarf and yawp when they see lower
case i because it means to them an integer, unless it means something
else.

Within other circles words are used and mean differently. For example,
in a circle I'd dearly love to join, swimsuit means bikini.

Which is why you wanna use the notation of the goddamn Magyars.

It is because using ANY vocabulary is doomed because you cannot
control the readership of the text in a globalized economy, where you
have no control over whether management, bless their hearts, will send
your text to Suva, Bora-Bora, Minsk, Hyderabad, or the shimmering Moon
for open-heart surgery.

But a reading of de Saussure shows us that STRUCTURE, and not words,
creates meaning. The notation of the Magyars creates STRUCTURE in the
meaningFul, camel-shaped break between the t and the I in the very
beautiful identifier intIndex.

> The following are from Microsoft?s guidelines for parameter names:
> -------------------------------------------------------------------
>
> Use names that describe a parameter's meaning rather than names that
> describe a parameter's type. Development tools should provide meaningful
> information about a parameter's type. Therefore, a parameter's name can be
> put to better use by describing meaning. Use type-based parameter names
> sparingly and only where it is appropriate.

Despite all this talk about "Meaning", what we find when we open real
program texts is almost universally a lack of meaning...despite the
use of well-intentioned words.

For example, customers tells me nothing about the object except that
it has "something to do" with the poor slobs who walk into my little
shop.

What we discovered in the 1960s was that the ersatz meaning of
management-speak is not only not enough to understand software. We
also discovered that it GETS IN THE WAY, and our discovery was
encapsulated in hero computer scientist Dijkstra's aphorism that "the
problems of business management are beyond the capabilities of
managers who speak in IBMer-ese and sloppy English".

Whereas colCustomers makes a start on telling me, ok, this is a
collection, a set of customers. It has structure. Gee I wonder what
will happen if I put a dot after it. Oh cool, there are my old friends
Add, Count, Item and Remove.

I think the war on the Hungarians is really a war upon the
phenomenology of work.

Cf Harry Braverman's Labor and Monopoly Capital. The practice of
structured programming and OO programming, like Hungarian, were
reflective of the minute-to-minute phenomenology of conscious
programming, as opposed to sitting around a meeting and bullshitting,
or mindlessly using copy and paste to create a mess. But the idea that
a programmer might be consciously creating a large structure is
anathema to American management for the very good reason that it
represents a violation of the Taft Hartley act, a Rust Belt law of
1948 due for repeal, which essentially says, when I want your opinion,
when I want your business rules, I will beat them out of you. Think
when I tell you and then please stop.

>
> Do not prefix parameter names with Hungarian type notation.
>
Sounds like Hungarian is a terminating offense DESPITE the fact that
Szymonyi was able to do so much great code with it. It's almost as if
the great coders of the past want to kick away the ladder by means of
which they climbed to the stars, and leave junior coders hacking away
with "meaningful" names that conceal important meanings.

Dijkstra's structured programming, and Szymonyi's contribution, are
perhaps offensive because they were efforts to actually mentor and to
pass on grassroots knowledge in a society which has become, in the
words of Robert Bly, a sibling society...in which nobody really cares
about creating meaning, only keeping secrets.
 
> The following is from Microsoft?s guidelines for property names:
> -----------------------------------------------------------------
>
> Do not use Hungarian notation.

It's almost as if Hungarian notation is Hamlet's father's ghost:

     "Thou art a scholar: speak to it, Horatio"

which squeaks and gibbers on the ramparts of Redmond, for the standard
tells the Microserf to use meaningful words when in fact he probably
doesn't have a clue where the meanings are, unlike Emily Dickinson:
who saw them in the silences of a winter's afternoon. The standard as
it is written encourages anarchy while pretending to encourage
discipline, for it explicitly urges the abandonment of a discipline.

It is a normalized deviance. C'est une deviance normale in
grenouille-speak. And, normalized deviance is the problem de notre
temps, because what it is, is a war upon grassroots efforts to make
sense in the name of a single, hegemonic narrative.

Quantcast