you know I just read the link someone gave to the paper by the creator of HN. Modern usage is nothing like what he envisioned. He didn''t say to name things after what type they are, but after the abstract type. Two totally different meanings, you have corrupted his noble purpose.

Since I''ve been busy, I''ll reply to some older crud.

Your example is flawed, because I couldn''t care less about the member variable aspect if I''m not using C++, secondly, I don''t care whether it''s a byte/dword/whatever because current processors and compilers will optimise to handle dword quantities. Further, so I have to solve a simple unsigned/signed warning - do I care?

No, not really.

And no, I don''t have a conspiracy theory, the first statement was kinda meant as a jest in the direction of the zealots, defined by people who actually pick up on it.

-Mezz

I think it is quite ugly, and made the code harder to read at a first glance.

Then I started writing more & more code. I didn''t really decide to start using HN, I just did.

...
You always want to know if something is local, member, or global, and it is always useful to know the type. And it is a pain in the ass to look it up, even if it is just one scroll away.


Magmai Kai Holmlor
- The disgruntled & disillusioned

As projects get larger in scope HN makes them a lot easier to manage. If it is some quick hack that will probably only take 10-15mins to put together and will never be looked at again... why bother?

Personally I like HN because it makes life easier, and after a while you just read it naturally (i.e. dwFileSize becomes ''a variable that is of size DWORD that holds the file size'') makes life much simpler.

Do you require HN in your code? well the simple answer is this: When you look at a previous month''s code can you understand it? An easy test... write code to do something... a bitmap loader... whatever. Write this code using HN and without it... don''t look at either for a month, put them out of your mind. Look back at them, which is easier to understand?

I like HN and use it all the time, I also like my code to be readable. I generally comment every function with a line about what it does, what it returns, etc. Then I comment every MAJOR step of the function.

This all goes back to how you prepare to code, namely... if you reduce problems to simpler steps. this makes it easier to comment.



Regards,
Nekosion

quote: Original post by Magmai Kai Holmlor
You always want to know if something is local, member, or global, and it is always useful to know the type. And it is a pain in the ass to look it up, even if it is just one scroll away.

You see, I''ve posted on this point before, so I may as well do it again.

You should generally have so few globals, that anyone using the program will know what they are very quickly anyway.

Your functions should generally be short enough so that you can see your local variable declarations onscreen 90% of the time. Especially so in C++, where you can (and probably should) declare variables near they are first used, rather than at the top of the function. I find that I very rarely need to write functions that don''t fit on the screen, and when I do, it''s because they are heavily commented, which is just as useful as these naming conventions.

Everything else, therefore, is a member variable.

I just find that all this m_lpstrName (yeah, I know, that probably isn''t proper HN) business just serves to make the code less readable, and seems to place more emphasis on the type of the variable than the purpose of the variable, which to me is the wrong way around.

One nice thing about using scope information in prefixing is that the number of occasions of variable hiding confusion go down. Especially between local variable/function arguments and member variables. And call me a weirdo, but when using prefixes I tend to also annotate function arguments with scope information as well. (Add a_ to g_, s_ and m_). That''s primarily a hold over from working in D!, a dialect of C that had allowed nested functions, and even then the a_ was also decorated with the nesting level. e.g. a_, a1_, a2_, etc.

quote: Original post by Muzzafarath

Hungarian notation is evil.

nuff said!

pi~

I don't use Hungarian Notation because it just adds an extra level of complexity to the code. As if C/C++ code isnt hard enough to read already, without all the "p", "l", "d", "w" and whatever else everywhere.

I use the Sun style instead, mostly because I also program in Java and want my code to look consistent in both Java and C++.

The problem with all the Microsoft APIs is that they all use hungrarian notation so half of my code is full of notation and half of it isnt, which is one of the main reasons I have given up Windows programming (for now) and am focussing on Java instead.

- Daniel
My homepage


Edited by - deakin on December 10, 2000 6:21:52 AM

I only have two globals in my entire game engine:
- "long value", to which I store the return values of functions. I declare this globally so that I don''t have to declare it in every function.
- An instance of my engine''s "main class", which handles the modules of the engine, the application window, messages, errors and logging.

-Jussi

Is the argument any naming standards or merely Hungarian? Because I''m sure about everyone has some standard they use.

Personally, I think Hungarian is a pretty ugly standard. Some things will never change, like i for integer, l for long. But personally, I think what people screw up on, is not naming the variable itself properly. They might get every prefix right, but it is the word after that that is important, not the prefix.

Variables with the name like pointer, or counter, or i...


Also, someone said Hungarian helps deal with the scope. And granted, projects do get big, and knowledge of where your variables are declared is helpful, BUT, if the code/module/project is designed and implemented properly. These things should be obvious without the prefix.