🔒 Locked
Hungarian Notation?
Advertisement
Original Post
I use hungarian notation when i write code.
It makes it easy to see what kinde of type your variable is.
You will not have any problems with casting that you can''t see.
If you use the prefix "m_" before your membervariables in your class you could see where to look for it in your code.
ex. int m_iX, m_iY;
Hungarian notation makes your code a lote easier to read
and your development team will be happy :-)
One problem is, shall i use hungarian notation when i write Java or C# code ?
Happy Hacking. Don''t forget to eat and sleep
It makes it easy to see what kinde of type your variable is.
You will not have any problems with casting that you can''t see.
If you use the prefix "m_" before your membervariables in your class you could see where to look for it in your code.
ex. int m_iX, m_iY;
Hungarian notation makes your code a lote easier to read
and your development team will be happy :-)
One problem is, shall i use hungarian notation when i write Java or C# code ?
Happy Hacking. Don''t forget to eat and sleep
I always use it, and have since I started programming DirectX 5 back in the day. It just makes sense to me to be able to tell at a glance what a variable is, and I find it particularly useful in C++ object design. I''ve also been complimented by a few coder-friends, on the legibility of my code.
On the flipside, I find some ''lazy'' notation annoying, such as:
float someVariableAmount; (small-first, then capitalized-case; VB-ish)
short some_variable_amount (lowercase, underscore separates words; too UNIX-ish)
I suppose consistency is the most important factor when designing source-code for readability, but it should be logical and legible, not pretty (and certainly not ugly!). Check out any ''open source'' UNIX/Linux program''s source-code, and prepare for cardiac arrest!
MatrixCubed
http://MatrixCubed.cjb.net
On the flipside, I find some ''lazy'' notation annoying, such as:
float someVariableAmount; (small-first, then capitalized-case; VB-ish)
short some_variable_amount (lowercase, underscore separates words; too UNIX-ish)
I suppose consistency is the most important factor when designing source-code for readability, but it should be logical and legible, not pretty (and certainly not ugly!). Check out any ''open source'' UNIX/Linux program''s source-code, and prepare for cardiac arrest!
MatrixCubed
http://MatrixCubed.cjb.net
quote:
Original post by Oscar A
One problem is, shall i use hungarian notation when i write Java or C# code ?
Please don''t. Both the official Java naming convention and the official C# naming convention disapproves of Hungarian.
Faith. n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. -- Ambrose Bierce
quote:
Original post by Arild Fines
Please don''t. Both the official Java naming convention and the official C# naming convention disapproves of Hungarian.
The same goes for Delphi:
quote:
From the Object Pascal Style Guide
Delphi is created in California, so we discourage the use of notation, except where required in header translations
quote:
Original post by MatrixCubed
I always use it,
Ugh. It''s awful.
quote:
and have since I started programming DirectX 5 back in the day. It just makes sense to me to be able to tell at a glance what a variable is,
So why not... give the variable an informative name? The compiler already knows the type. The IDE already knows the type. Prepending the type to the variable''s name is just redundant clutter.
quote:
and I find it particularly useful in C++ object design. I''ve also been complimented by a few coder-friends, on the legibility of my code.
I''ve not seen any C++ code that uses hungarian that wouldn''t be clearer without the warts and with properly-named variables.
quote:
On the flipside, I find some ''lazy'' notation annoying, such as:
float someVariableAmount; (small-first, then capitalized-case; VB-ish)
short some_variable_amount (lowercase, underscore separates words; too UNIX-ish)
What do you mean, lazy? How would you form multi-word variable names?
quote:
I suppose consistency is the most important factor when designing source-code for readability,
http://www.bartleby.com/100/420.47.html
quote:
but it should be logical and legible, not pretty (and certainly not ugly!). Check out any ''open source'' UNIX/Linux program''s source-code, and prepare for cardiac arrest!
Hungarian is rarely logical, never legible, and invariably ugly.
I don''t really use it, but I do use the following:
protected member variables: prefix pro_
private member variables: prefix pri_
public member variables: prefix pub_
pointer: prefix p or lp
Hehhe.. I use pro, pri and pub becuase I could never figure out what the "m_" stood for. Now I know, and I kinda wish that I had used that instead. Too late now, but for my next engine I''ll use m_. I''m kindof thinking about using g_ for global variables, but I''m not really sure. Usually whenever I make something global I''m just experimenting.
¬_¬
protected member variables: prefix pro_
private member variables: prefix pri_
public member variables: prefix pub_
pointer: prefix p or lp
Hehhe.. I use pro, pri and pub becuase I could never figure out what the "m_" stood for. Now I know, and I kinda wish that I had used that instead. Too late now, but for my next engine I''ll use m_. I''m kindof thinking about using g_ for global variables, but I''m not really sure. Usually whenever I make something global I''m just experimenting.
¬_¬
I use(d) hungarian since it was first pushed by MS, it made sense at the time, back in the days when types were simple.
These days when objects are virtually typeless (determined at run time). What are you going to prefix things with? ''obj''?
The only things I do in hungarian are members (m_) globals (g_) and statics (s_), beyond that it is almost pointless. It can confuse when the type of an object changes.
D.V.
Carpe Diem
These days when objects are virtually typeless (determined at run time). What are you going to prefix things with? ''obj''?
The only things I do in hungarian are members (m_) globals (g_) and statics (s_), beyond that it is almost pointless. It can confuse when the type of an object changes.
D.V.
Carpe Diem
quote:
Original post by Zipster
That''s interesting, I didn''t know there was an official statement.
If you need an "official statement" to convince you of something, then it seems thinking for yourself is beneath you.
quote:
Original post by DeltaVee
The only things I do in hungarian are members (m_) globals (g_) and statics (s_)
That''s not Hungarian.
I agree with some of the earlier posts - hungarian notation makes little sense as soon as you start talking about more interesting classes or types. Even if you could encode the type cleanly, why would you want to? I''ve been on projects where we started with a CString, then moved to our better CBetterString and then moved to some other CBestStringWithBellsAndWhistles.
If I name the variable m_NameString, I can change the type on the fly. If I want to adhere to hungarian notation, I have to rename the variable every time. In this case, h. notation actually makes updates more difficult.
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces"
If I name the variable m_NameString, I can change the type on the fly. If I want to adhere to hungarian notation, I have to rename the variable every time. In this case, h. notation actually makes updates more difficult.
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces"
quote:
Original post by DeltaVee
I use(d) hungarian since it was first pushed by MS, it made sense at the time, back in the days when types were simple.
No.
It made some degree of sense when people were developing in C. C effectively has no typechecker -- it is up to the programmer to check he doesn''t fuck things up.
But even C had tools such as lint.
With C++ the compiler does this job for you, so you don''t have to.
quote:
Original post by DrPizza No.
It made some degree of sense when people were developing in C. C effectively has no typechecker -- it is up to the programmer to check he doesn''t fuck things up.
But even C had tools such as lint.
With C++ the compiler does this job for you, so you don''t have to.
Let me clarify. I first read about hungarian notation back in the eighties. When MS released Windows they adopted a Hungarian Notation based type naming scheme, at the time it clarified code immensley. Especially when you were dealing with programmers that could not compile their code with the STRICT manifest constant defined. IIRC 4-5 years later C++ became popular enough for MS to produce a compiler for it.
It has been my experience that alot of Hungarianesque Notation is ''perpetrated'' by us old farts, and those learning Windows programming for the first time.
D.V.
Carpe Diem
I used to prefix all private variables with underscores (ala Relisoft) but that just got too visually annoying.
Here''s what I do (in C++ anyways, I use the suggested C# naming convention)
CapitalCase for functions, methods, class/struct names, and typedefs
camelCase for local variables and objects
m_ for member vars
s_ for static vars
p_ for pointer vars (replacing)
g_ for global vars
I try to use descriptive names enough to the point that the name of the variable represents it''s type. Also, I tend to mix and match too: mp_ = member pointer, sm_ = static member, gp_ = global pointer, etc...
Here''s what I do (in C++ anyways, I use the suggested C# naming convention)
CapitalCase for functions, methods, class/struct names, and typedefs
camelCase for local variables and objects
m_ for member vars
s_ for static vars
p_ for pointer vars (replacing)
g_ for global vars
I try to use descriptive names enough to the point that the name of the variable represents it''s type. Also, I tend to mix and match too: mp_ = member pointer, sm_ = static member, gp_ = global pointer, etc...
I just use m_ for member variables, g_ for global, p for pointers. That''s it.
My compiler generates one error message: "does not compile."
My compiler generates one error message: "does not compile."
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement