Re: Hungarian notation

[Graham Perkins <grp@dmu.ac.uk>]

Re: Hungarian notation and CJIIIRR
----------------------------------
> Stop posting this banal thread, which has nothing to do with Eiffel, to
> comp.lang.eiffel.

It most certainly has much to do with Eiffel.  I assert that

  a) Developing good naming schemes is a critical part of 
     any software development project.

  b) Hungarian notation is used in some large projects (eg
     Microsoft products)

  c) Software developers should be aware of software engineering
     techniques used in large products and how applicable they are to
     the particular language/project they are embarking upon.

In particular, point (c) above could include software developers
working with Eiffel.

Re: Hungarian notation
----------------------
A careful reading of chapter 9 in "Code Complete" by Steve McConnell
(published Microsoft press) reveals much good advice.  As it happens,
much of the recommended naming structures (Hungarian and otherwise)
can be dispensed with by Eiffel programmers as they are geared to C
like languages.  But some aspects are entirely relevant.  The intelligent
reader will be able to see how Eiffel automatically supports many of
the goals of Hungarian notation, and how other goals still need to
be addresses.

Bertrand Meyer's book "Reusable Software" also addresses identifier
naming schemes in the chapter on library design.  I thoroughly 
recommend it to all software library designers, Eiffelists or not.

Re: Naming schemes in general
-----------------------------
Some of the issues addressed in "Code Complete" can be bypassed by the
Eiffel or general OO programmer.  For example, metrics published in 
the "Object Oriented Applications" book (eds. Bertrand Meyer & Jean-Marc 
Nerson, pub. Prentice Hall) indicate that most classes are not large
(average 5-14 features, depending on which cluster) and most methods 
are also fairly short (2-13 lines depending on cluster).  Thus it is
probably not worth bothering to distinguish scope, since locals will
only be a few lines away and all other id's will be qualified by their
owner's name anyhow (unless belonging to Current).  There are no
statics or globals in Eiffel, so we don't need codes for them either.

The presence of multiple inheritance is quite relevant, since we can
place our names high up in abstract classes (effectively determining
common names across many descendant classes).  Without working on the
commonalities across low-level concrete classes, the programmer will
miss many opportunities for ancestor delegation or at least ancestral
specification.

> Colin James III
> cjames@bod.boss.net
> Do not send harassing email to me.

According to replies from this address, this user bounces *all* email.