Arguments against Hungarian Notation

[Rob Wehrli]

Kimbro Staken wrote:
> 
> Hungarian came out of Microsoft from the C and C++ world, I suspect VB
> people just picked it up out of imitation without really understanding
> what it was for.

Don't be a fool.  The VB programmers at Microsoft (and many other
places!) aren't stupid monkeys and just started using it "without really
understanding what it was for."  I don't mind poking fun at VB and even
a few other languages, but its programmers are not some version of
mutated pygmies from Mars.  They are intelligent humans with strengths
and capacities that enable them to write useful applications for
Windows.  Charlie Simonya "invented" Hungarian notation...or at least,
his use of it and his Hungarian ancestry represent our collective
understanding of the combined words and their meanings.

> 
> The best argument you'll have is that it isn't part of the Sun coding

True.  Hungarian is not part of the "standard" Java coding convention
from Sun.  ...but, the standard doesn't say NOT to use it, either.

> conventions for Java. [1] It is also pretty useless in a pure OO language
> where you don't have pointers, it really just obfuscates the code.

Huh?

public class BadCode
{
  public	String 		a = "Using Hungarian Makes Sense."
  public	boolean		b = false;
  public	Boolean		B = new Boolean( false );
  public	int		i = 0;
  public	Integer		I = new Integer( 0 );
  public	char		c = 'c';
  public	Character 	C = new Character( c );
  public	double		d = 12345678.12345;
  public	Double		D = new Double( 12345678.12345 );
  public	float		f = 123456.7890F;
  public	Float		F = new Float( 123456.7890 );

  public BadCode()
  {}
}

versus

String 		strName 	= "Charles Simonya";
boolean 	bIsRaining 	= false;
int		iCounter	= 0;

I don't see how the Hungraian "obfuscates" the code...I can see how it
would dramatically HELP the code...

Note this class (fragment) that I wrote for a simple racing "stats"
thing for one of the local drag racing clubs where I participate.

public final class Car
{
	long lPrimaryKey;
	int iRacesThisSeason;
	int iPointsThisSeason;
	int iMatchesThisSeason;
	int iMatchPointsThisSeason;
	String strNumber;
	String strOwner;
	String strYear;
	String strModel;
	String strColor;
	String strMotor;
	String strInduction;
	String strNitrous;
	boolean bLicensed;
	String strBarCage;
	String strTireType;
	String strTireWidth;
	String strNotes;
	String strLocation;

...
}

What is so obfuscating about that?

> Basically if almost everything is an object then every variable ends up
> with an o or something similar on the front. It won't even help for stuff
> that isn't an object as the compiler can easily keep track of the types.

You don't generally need to have a "type identifier" for a class, since,
if it isn't a "basic" type, it is a CLASS.  The primary exception to
this in Java tends to come from the "basic type classes" such as
Integer, Float, Double, Character, Boolean etc...

int 		iCounter;
Integer 	what do we do in these cases?  oCounter?

> Plus virtually no java programmers use it because of the Sun conventions.

I don't know about that...I know many Java programmers who use it
because it makes sense.  Sun simply stipulates that variable names begin
with lowercase, use "camel backing" of variable names, and classes start
with a capital.  They also recommend not using underscores in names and
all uppercase for static final members...if my memory serves me
correctly.

> 
> Also if you want a Microsoft oriented argument, tell them that not even
> Microsoft uses it anymore with C# as part of .Net.
> 
> Next up you'll have to battle them over wanting to stick an I on the front
> of every interface name. That's just obfuscation too.

How can it possibly be obfuscation?

IListenerBroadcast
ITerminalOutput

...I can see how the "I" really *destroys" the ability for you to make
any comprehension from the code.  Here is obfuscation...

#include <stdio.h>
main(t,_,a)
char *a;
{
return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):
1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\
;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw'
i;# \
){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n'
')# \
}'+}##(!!/")
  :t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
    :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);
}


...see any difference?  I'm thinking that perhaps your "obfuscation"
comment is slightly exaggerated based on your bias toward NOT seeing HN?


> 
> [1] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
> 
> On Friday, May 3, 2002, at 07:30 AM, Carl Parrish wrote:
> 
> > Okay I *long* ago decided to give up on Hungarian Notation. (I think
> > only VB programmers seems to like it). I now find myself in a shop with
> > a *lot* of previous VB programmers who are converting to Java. So I want
> > them to stop using hungarian notation. So far the only argument against
> > it I could remeber is that it violates OO abstraction. But I *know*
> > there are better arguments against than that. Anyone have any sources or
> > know of any good reasons against?
> >
> > Carl Parrish
> >

Also, there is something to be said about being flexible enough to
understand BOTH sides of the topic.  I can understand not wanting to
"convert" to HN, but I don't see the need to justify it as "obfuscating"
the code.  The goal of HN is to make the code CLEARER, and it does,
whether or not you've accustomed yourself to accepting it or not.  I
even use HN in naming my XML attributes...where the types must always be
the same within the "code" (xml file) but handled differently in the
parser.  I think that there are certainly different strokes for
different folks, but this is not a religious thing.  If you following
Sun's Java coding standards and conventions, you probably also use the
(early) K&R style of braces:

void myfunction( void ) {
}

..rather than...
void myfunction( void )
{
}

...or...
void myfunction( void )
  {
  }

...and, just because it is SUN's convention, doesn't mean that YOU have
to use it.  Sun has their conventions, other shops have their own.  The
entire idea of conventions is to modify them to suit the needs of the
team.  Individual programmers don't need "conventions" because they each
have their own "style."  Teams need conventions that all of the
programmers can at least live with in order to maintain consistency
throughout the life-cycle(s) of applications.

I say that if you (Carl) are trying to come up with an attack against HN
to sell management on it to somehow displace "a *lot*" of VB
programmers, you're fighting the wrong fight (I think that Alan said it
first).  Better to deal with the better thing for the largest group in
this case, IMHO.  ...fight for features, environmental benefits or
something else worth fighting for and winning.  Your life won't
seriously be threatened as a result of using HN.

I say that if you (Kimbro) are consulting and run into a crap-load of
code where the types of the variables take hunting through several dozen
files, globals are "just out there" (versus g_myvar) and everything
looks a helluva lot like spaghetti...your productivity will be rapidly
diminished and would be immediately improved if HN were used.  You don't
have to agree with me.  Different people have different capacities for
keeping things floating around in their heads.  Me, I don't want to be
bothered with trying to remember 60 different types for the various
members in code.  Other kinds of programmers seemingly don't feel
comfortable unless they HAVE to keep them in their heads just to know
what they are 3 pages into it.  Of course, if everyone wrote code that
fit neatly into a third or half a screen of 24 columns, we wouldn't need
HN.

I was reviewing a guy's code.  It was Win32 C code using C++ as a
"better C."  His Windows Procedure (Windows message handler) was like
680 lines of code.  To me, that is obfuscation!  Bury the details of it
in the code...line after line after line so that you had to have written
it to figure it out.  Furthermore, he used "C" conventions
(requirements) of placing variables "first" in his code and he did not
use HN.  It is a PITA having to flip back and forth between two open
views of the same code, one tracking where you're at in the code and
another on the top at the variable declarations.  HN removes this
requirement.

I don't ask that you or anyone else use HN if it doesn't match your
"local" conventions/standards.  I do, however, ask that if you must use
a global, at least indicate it using HN.  Modern IDEs easily denote
globals and other members with current-scope resolution.  However, when
was the last time you were in a peer code review with an IDE in front of
you and not a stack of printed code?  It isn't much fun sitting through
such sessions trying to figure out what a variable type is deep within
the code.


Take Care.

Rob!