• Advertisement
Sign in to follow this  

do you guys use Hungarian notation?

This topic is 2773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have heard that Hungarian Notation is not recommended by Microsft and Bjarme Stroustup, the creator of c++. What notation do your recommend?


Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by becoolnike
I have heard that Hungarian Notation is not recommended by Microsft and Bjarme Stroustup, the creator of c++. What notation do your recommend?
My heartfelt recommendation is that you forget you ever heard the word "notation", and just get on with writing the damn code.

If you have to deal in such pedantic terms, then anything *except* Hungarian is the way to go...

Share this post


Link to post
Share on other sites
Ah, the great Hungarian Notation Debate.. soon to fill with flames I'm sure.

However, I'm going to go out on a limb here and say that practically everyone uses a variation on what I like to think of as Modern Apps Hungarian.

Unlike System Hungarian, which encodes type information into the variable name (for example fWidth meaning a floating point type) Apps Hungarian, which iirc was the first Hungarian Notation invented, encodes usage information into the variable name (for example colWidth meaning 'column width' or sName meaning 'safely encoded name').

Now, while there are still those out there who use System Hungarian (and my god have mercy on their souls for it) they, and indeed others, will still encode usage information into the variable names, because that makes sense.

The reason I referred to it above as 'Modern Apps Hungarian' is because instead of using short hand for a variable name, such as colWidth, longer more descriptive names are used; columnWidth for example.

The semantic infromation is still encoded, we just aren't pandering to 80 column screens or editors without syntax completion any more [wink]

There is some variation on this of course; case of laters, underscores or not, pre and post-fix information to indicate scope, but in general I would say "Modern Apps Hungarian" prevails because it makes sense.

Share this post


Link to post
Share on other sites
Quote:
Original post by becoolnike
I have heard that Hungarian Notation is not recommended by Microsft and Bjarme Stroustup, the creator of c++. What notation do your recommend?
They're talking about "Systems Hungarian", not "Apps Hungarian".

Share this post


Link to post
Share on other sites
To expand on what phantom said, the original Hungarian was developed based on the observation that int width; is a dangerous way to handle variables when width can be in pixels, twips, inches, centimeters, or bits. Instead you use pxWidth, and now it's a pixel value. Sadly this was corrupted to re-encode the variable's explicit type, and worse still people actually thought it was a good idea to do so.

Share this post


Link to post
Share on other sites
In short, it was from an era when you couldn't just hover your mouse over the variable name, and get a nice little popup with it's type and comment right there for you. Also, certain compilers could only identify the first x characters in a variable name uniquely (usually 8 I believe).

Now you can easily write int HowMuchWoodCanAWoodChuckChuckIfAWoodChuckCouldChuckWood if you want to.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daaark
In short, it systems hugarian was from an era when you couldn't just hover your mouse over the variable name, and get a nice little popup with it's type and comment right there for you.
Unambigufied ;)
Apps hungarian attaches information to the name that you can't find out by hovering your mouse over something (like in promit's example: whether the int is counting in pixels or inches).

There's a long essay on the corruption of hugarian and it's proper use on Joel on Software.

Share this post


Link to post
Share on other sites
What about Java beans-like style? Do you guys think it's a good idea to use it on C++ code?

Share this post


Link to post
Share on other sites
Personally , I just really care about things being uniform. If multiple people are working on the same code, I just want things to be consistent and have some logic behind the structure of variable names.

Share this post


Link to post
Share on other sites
Quote:
Original post by andrew1b
What about Java beans-like style? Do you guys think it's a good idea to use it on C++ code?
Especially in Java and C++ it is silly, in my opinion. As Promit said, there used to be a good and valid reasoning behind it originally, as given by the pxWidth example.

However, if one uses that system to distinguish an integer from a string etc. in a language with strong typing, then one simply hasn't understood how the language works.
The compiler will make sure you don't accidentially use an incompatible variable type. It simply isn't possible to confuse types (except for implicit conversions which are legitimate) if you care to hit the compile button before checking in your source (and if you don't verify that your code compiles before checking in, you'll probably get fired, anyway). Plus, modern IDEs figure out types even while you type, so you usually don't even need to go through the compile cycle to spot possible errors, the compile is only the last assertion that everything is correct.
Thus, there is no real benefit in making variable names less readable. A variable name (like all code) should be descriptive so one can understand the code, no more, no less. If some notation can convey useful and important information, that is fine. However, if it only copies something the language already does, it is just noise.

Share this post


Link to post
Share on other sites
What about the 'is' prefix for boolean type?

getEnabled or isEnabled?

Does it matter? What do you think is the best practice (C++)?

Share this post


Link to post
Share on other sites
Quote:
Original post by andrew1b
What about the 'is' prefix for boolean type?

getEnabled or isEnabled?

Does it matter? What do you think is the best practice (C++)?


If you prefer so, find it easier to read or whatever reason, then use it. I generally find 'enabled' enough:

if (enabled) // sounds like not too bad English
if (is_enabled) // sounds awkward, should be something like 'if it / this / [object name] is enabled'

// English wise, it'd even be better to write:
when (enabled)

Share this post


Link to post
Share on other sites
There was a brief time when I did, but I got over it. With VAX and Alt-G, I think a good comment works a hell of a lot better than some sort of cryptic notation scheme.

For a while I still made an exception for shader code, since you don't have anything like VAX or Intellisense available. But even for those I got sick of making the code ugly and harder to read. Now the only "notation" I use is a suffix for position and direction vectors that indicates which coordinate space they're in (WS, VS, etc.).

Share this post


Link to post
Share on other sites
Just a little side question:


_Myt& replace(size_type _Off,
size_type _N0, size_type _Count, _Elem _Ch)
{ // replace [_Off, _Off + _N0) with _Count * _Ch
if (this->_Mysize < _Off)
_Xran(); // _Off off end
if (this->_Mysize - _Off < _N0)
_N0 = this->_Mysize - _Off; // trim _N0 to size
if (npos - _Count <= this->_Mysize - _N0)
_Xlen(); // result too long
size_type _Nm = this->_Mysize - _N0 - _Off;

if (_Count < _N0)
_Traits::move(_Myptr() + _Off + _Count,
_Myptr() + _Off + _N0, _Nm); // smaller hole, move tail up
size_type _Num;
if ((0 < _Count || 0 < _N0)
&& _Grow(_Num = this->_Mysize + _Count - _N0))
{ // make room and rearrange
if (_N0 < _Count)
_Traits::move(_Myptr() + _Off + _Count,
_Myptr() + _Off + _N0, _Nm); // move tail down
_Chassign(_Off, _Count, _Ch); // fill hole
_Eos(_Num);
}
return (*this);
}


What notation is this? Is this Hungarian, too? I'm asking because I can't understand in less than 5 minutes looking at it what this code should do.

Share this post


Link to post
Share on other sites
There's nothing "Hungarian" about that code. I guess you're referring to the fact that identifiers begin with an underscore and a capital letter, but I doubt that underscores are the reason you're having trouble reading that code. More likely, it's just that the code is somewhat dense, and it's using helper functions you're not familiar with. replace() is also necessarily a complicated function to implement in an efficient manner, because it can make the string longer or shorter.

Share this post


Link to post
Share on other sites
The C++ standard reserves certain identifiers for use by the implementation. All other identifiers are allowed to be used by the user for whatever use they want. This includes as arguments for #defines. As a consequence standard library code usually uses those reserved identifiers exclusively in their implementations.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Unlike System Hungarian, which encodes type information into the variable name (for example fWidth meaning a floating point type) Apps Hungarian, which iirc was the first Hungarian Notation invented, encodes usage information into the variable name (for example colWidth meaning 'column width' or sName meaning 'safely encoded name').


I've been using prefixes for pointers (*p) and for pointers to pointers (**pp). Personaly, I find it helpful and it makes it easier (at least for me) to read the code. I know it's unecessary since the compiler can easely tell it, but when I look at the whole piece of code, those prefixes help me a lot.
These are the only prefixes I still use (although I used to write a lot of extremely unecessary ones lately).

Do you guys think that's a bad habit? Shall I avoid it at all costs?

EDIT: I also use m_ prefix for class members. Is that ok?

When I ask "is this OK" I'm asking "is this what most expert programmers and greatest companies do?"

Share this post


Link to post
Share on other sites
Quote:
Original post by andrew1b
Do you guys think that's a bad habit? Shall I avoid it at all costs?
I think the first question to ask is, how many raw pointers (and pointers to pointers) do you have in your code? In well-formed C++ code, there should (arguably) be very few (if any) raw pointers, so that's probably the first thing you'll want to look at.

As for the prefix, I wouldn't use them, but that's just a personal preference.

Share this post


Link to post
Share on other sites
When i wrote c++ (studying) i mainly used m_,g_ and Ptr.
Was enough for me..

Now i write c# in a biz ( and we use an _ for private members and a variety of uppercase & lowercase for functions and/or members, so no, not really, most important is still clear naming of variables.. and lots of commentary

But this is just my opinion.

If you feel inclined to use it, then please do :) just don't overdo it

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Quote:
Original post by andrew1b
Do you guys think that's a bad habit? Shall I avoid it at all costs?
I think the first question to ask is, how many raw pointers (and pointers to pointers) do you have in your code? In well-formed C++ code, there should (arguably) be very few (if any) raw pointers, so that's probably the first thing you'll want to look at.

As for the prefix, I wouldn't use them, but that's just a personal preference.


Sometimes there's no escape. Many libraries I use work with pointers to virtual classes (TinyXML, AngelScript and others).

Share this post


Link to post
Share on other sites
Quote:
I also use m_ prefix for class members. Is that ok?
I think quite a few folks who otherwise avoid name prefixes still use 'scope' prefixes such as m_, s_, and g_. There have been some good arguments made against them here on the forums, but if you find them helpful, I'd just use them and not worry about it too much.
Quote:
When I ask "is this OK" I'm asking "is this what most expert programmers and greatest companies do?"
What the 'greatest companies' do probably isn't terribly relevant.

Lots of big companies have codebases and coding standards that have been around for years, and therefore may incorporate styles and practices that aren't so much in favor now. For someone who's starting a new project from scratch though (or otherwise doesn't have to contend with a lot of inertia), there's really no need to adopt such practices.

As for what expert programmers would do, I think most experienced coders writing modern, idiomatic C++ would avoid type prefixes of the kind under discussion here. That's just the impression I get though (I don't really have any data to back that up).

In any case, I wouldn't worry too much about what others are doing. If you can clearly quantify how and to what degree type prefixes help you, personally, develop software more effectively, then use them. However, I would not recommend using them just because you've seen it done that way elsewhere.

Share this post


Link to post
Share on other sites
I use an intense bastardisation of it and drop it whenever it makes more sense XD

I mostly just use it to group things together in the auto-complete. It's easy to find all the private variables in a class when they begin with _pv_ ^^

In C++ I denote "usable" classes typically with C and classes intended to be inherited with I. In C# and Java, aka classes lacking multiple inheritance, I use I just for explicit interfaces, with B (base) for classes intended to be inherited but not interfaces because they implement some functions.

I also have a concept of "static interface" in C++ (SI) which is an implementation of the Singleton pattern but where only children can access the global data.

Private variables begin with _pv_, and static private variables _spv_ =P Protected variables are just preceded by _. Functions have no markings identifying them as such except beginning with a capital letter :P

Integers are also prefixed with n, and if the size of the integer is considered "important" I then mark the amount of bytes. This includes "char" when it is used for integers, not characters. When it's used for characters it's c. Things like that are simple enough to tell ^^ Pointers p then the type pointed to's identifier.

It sounds complicated but it's simple enough and like I said, almost entirely for auto-completion and keeping things organised on screen and in my head.

Share this post


Link to post
Share on other sites
Quote:
Sometimes there's no escape. Many libraries I use work with pointers to virtual classes (TinyXML, AngelScript and others).
True, sometimes when working with third-party APIs, you'll be stuck using pointers.

However, keep in mind that even then, 'raw' pointers can often be avoided. (Just as an example, resources that are managed via 'create' and 'free' functions - things like SDL surfaces and so on - can still be managed using smart pointers. So, just because an API deals with raw pointers doesn't necessarily mean that you have to deal with them directly in your own code.)

Share this post


Link to post
Share on other sites
Quote:
Original post by mind in a box
Just a little side question:


_Myt& replace(size_type _Off,
size_type _N0, size_type _Count, _Elem _Ch)
{ // replace [_Off, _Off + _N0) with _Count * _Ch
if (this->_Mysize < _Off)
_Xran(); // _Off off end
if (this->_Mysize - _Off < _N0)
_N0 = this->_Mysize - _Off; // trim _N0 to size
if (npos - _Count <= this->_Mysize - _N0)
_Xlen(); // result too long
size_type _Nm = this->_Mysize - _N0 - _Off;

if (_Count < _N0)
_Traits::move(_Myptr() + _Off + _Count,
_Myptr() + _Off + _N0, _Nm); // smaller hole, move tail up
size_type _Num;
if ((0 < _Count || 0 < _N0)
&& _Grow(_Num = this->_Mysize + _Count - _N0))
{ // make room and rearrange
if (_N0 < _Count)
_Traits::move(_Myptr() + _Off + _Count,
_Myptr() + _Off + _N0, _Nm); // move tail down
_Chassign(_Off, _Count, _Ch); // fill hole
_Eos(_Num);
}
return (*this);
}


What notation is this? Is this Hungarian, too? I'm asking because I can't understand in less than 5 minutes looking at it what this code should do.



Btw, why are all the standard headers so f***ing ugly?! Looking at standard C++ headers, I often get the impression those guys ran their code through an obfuscator program to make everything as hard to read as possible.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Btw, why are all the standard headers so f***ing ugly?! Looking at standard C++ headers, I often get the impression those guys ran their code through an obfuscator program to make everything as hard to read as possible.
Yeah it would be nice if it was a bit more readable, like this.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement