Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.c++.moderated
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Hungarian notation
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
James Dennett  
View profile  
 More options May 1 2001, 11:11 am
Newsgroups: comp.lang.c++.moderated
From: James Dennett <jdenn...@acm.org>
Date: 1 May 2001 11:11:32 -0400
Local: Tues, May 1 2001 11:11 am
Subject: Re: Hungarian notation
Print | View thread | Show original | Report this message | Find messages by this author

John Jacob wrote:

> Hello,

> I have been using c++ for a while, and mostly developed with MFC. After a
> while, I adopted the hungarian notation, it being the style used in most
> code I had come across.

Sad but true.

> However, I keep seeing opinions that hungarian should not be used.
> What are the actual disadvantages of hungarian?

[My comments apply to "Hungarian" notation as commonly used
in MFC etc., and not to smarter versions which encode only
abstract type information.]

It's a crutch for languages such as C which don't have such
a rich type system as C++.  In C++ it encodes in names
information which is not important; say I call my variable
vectorNames, because it's a std::vector, and later find out
that it ought to use a std::deque for performance reasons.
Then I'll have to either (a) rename it globally, or (b)
live with an incorrect name.  Not to mention that "names"
is a more readable name, and its terseness might encourage
a more descriptive name such as "employeeNames".

> Using hungarian does not
> affect speed or stability, and does not affect the person who wrote it.

It affects the person who wrote it by making them think
too much in terms of implementation details, and not enough
in terms of *meaning*.

> Variable naming is done so that the NEXT person who writes
> finds it easier to understand the code.

Possibly; it can aid uniformity, but at the cost of absolute
clarity.

> So, does hungarian make code harder to maintain?

As per by "vectorNames" example above, yes.  Hungarian
notation makes code harder to maintain.

> Does it make code more
> difficult to read?

Yes, because most of the types in good C++ code are not
primitive types, so you have to either (a) write a full
type name in your Hungarian wart, making identifiers
much longer for no gain, or (b) invent bizarre abbreviations
for type names which are a barrier to entry for those
wishing to read your code.

Not to mention that it's not clear how Hungarian notation
could apply in generic code.

> Are there any alternatives to hungarian - seeing that just naming variables
> at random can cause problems (e.g where a name "file" would be used in a
> single project to mean a handle to a file, a filepath, a CFile object etc.)

Maybe a meaningful name would avoid that: PathToConfigFile,
ConfigFileStream, ... .  I find that avoiding Hungarian
notation helps me to concentrate on the meaning of my
objects, where Hungarian notation leads people to name
objects often solely based on their concrete type.  The
meaning is usually more resilient through changes than
is the concrete type.

-- James Dennett

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google