Re: nit pickin'
From: Tim (Tim_at_NoSpam)
Date: 02/18/04
- Next message: Frank Hickman: "Re: File Print"
- Previous message: Tim: "Re: JPEG and GIF"
- In reply to: Steve Russell: "Re: nit pickin'"
- Next in thread: Balboos: "Re: nit pickin'"
- Reply: Balboos: "Re: nit pickin'"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 19 Feb 2004 11:21:33 +1300
There are good reasons for hungarian notation. Not so much these days,
but...
Years ago I was given the task of debugging someone elses C++ / database
code.
Table names were simple names EG Company. Field names were simple, then in
code, member and local variable names were also predominantly simple. This
is where the original programmer got stuck and created bugs - He / She had
to invent new names to get around the fact that the existing names were
already used and due to poor OO etc, confused the use. Huge mess.
It could not be fixed by simple edit / replace as there were bad hits
everywhere. (Function names were meaningless & a disaster). The source had
to be printed out and the renaming mapped, planned & executed. This was
extreme. The app itself was straight forward and easy to fix after that.
Benefit off HN
#1 - edit find will have near 100% hit on references.
#2 - edit replace will succeed.
#3 - code is more reliable if you are lousy at OO / learning.
OK, so you have to be a lousy programmer to get in this situation, but that
is exactly why these naming conventions are created - to stop people
becoming lousy or lazy programmers and think about what, when, why and how.
Now, if the original programmer above had written good OOD code rather than
dribble code, there would have been nowhere near as much of an issue.
My convention?
Meaningful Names.
InitialCapitals - no underscores, these do nothing to convey information.
Hungarian notation - relaxed for local variables.
Ditto for class names - to an extent.
EG all CEdit derived classes in one project are prefixed "edit", and so on,
but true Object Classes EG Account are simple names to reflect their "real"
world linkage. The advantage here is you can see all classes by type
derivation and rapidly find what you want.......
Hungarian itself does not give great benefit, it does get in the way if you
do change a datatype, but assists greatly in Edit Replace scenarios. Some DB
Designers once used hungarian notation for Column Names, but this is a
disaster since DB designs change and there are horrid flow on effects if the
data type changes both in the database and application / middle tier code.
- Tim
"Steve Russell" <srussell@innernet.net> wrote in message
news:#sZMXcm9DHA.2316@TK2MSFTNGP11.phx.gbl...
> Actually, I have wondered why I need to use Hungarian notation when the
> cursor will deliver a Type Info tooltip.
> ----------
> > I had to read/use that Hungarian notation. Another bad idea, gone sour.
> > It's the kind of thing a manager would pick up and force upon the
> > programmers.
>
>
- Next message: Frank Hickman: "Re: File Print"
- Previous message: Tim: "Re: JPEG and GIF"
- In reply to: Steve Russell: "Re: nit pickin'"
- Next in thread: Balboos: "Re: nit pickin'"
- Reply: Balboos: "Re: nit pickin'"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|