asm hungarian notation

[u]

btw, Joel Spolsky's got a great article on the subject . http://www.joelonsoftware.com/articles/Wrong.html  Read downwards from the "I'm Hungary" section. I wonder how I missed to read this article of his  :red .
PS:
In a nutshell, he explains how the Hungarian notation got misunderstood, and that useless misunderstanding was published as a standard. He shows what Charles Simonyi actually meant with it, and gives real-world examples of it, to show the notation's shine - that I find really useful. It's really just the notation, created/described by the people that first misunderstood it, that is useless crap.

BUT, the published misunderstanding of the Hungarian notation was overthrown for the reason that C/C++ have type-checking. In asm, there's no serious type-checking, so for us it can be helpful!

[sluggy]

BUT, the published misunderstanding of the Hungarian notation was overthrown for the reason that C/C++ have type-checking.

Exactly, hence my observation that hungarian notation is mostly useful for interpreted languages.

In asm, there's no serious type-checking, so for us it can be helpful!

You are right, but the type checking can be done by using equates, and then using the equates in your proc or variable definitions. To be honest, when coding asm i still sometimes use a "p" or "h" prefix when the type isn't obvious from the variable/parameter name.

[zooba]

I have a (reasonably) simple system for my variables:

QWORD, DWORD, WORD and BYTE values are prefixed with qw, dw, w or b.
DWORD pointers are prefixed with p
DWORD handles are prefixed with h
Strings (BYTE arrays) are prefixed with s
Strings (WORD arrays) are prefixed with su
Pointers to strings are prefixed with sp or sup
Functions have no prefix.
Structure variables have no prefix.

I'd rather be explicit in my variable names than implicit, especially as to whether something is a pointer or not, and spName is much easier than NameStringPointer, which I've seen suggested as a 'readable' alternative. I declare everything as DWORDs (even BYTEs and WORDs when passing them to a function, since invoke chokes occasionally) and don't use any typedefs at all, so all my prefixed variables are DWORDs and type-checking is pretty useless.

My favourite application of Hungarian notation is the recommended prefixes for controls in VB6. A lot of people disagree so don't bother flaming if it makes you angry, but txtName makes so much more sense than NameTextBox and mnuFile is much much better than VB2005's idea of FileToolStripMenuItem.

Cheers,

Zooba :U

[drhowarddrfine]

Hi!

How come that I am a hungarian but have never heard of "hungarian notation"? Why is it called hungarian?  :dazzled:

Greets, Gábor, the Hungarian :bg

No excuses Gabor.  I'm Hungarian and I've heard of it. 

Well, at least my father was.

Actually, my grandparents are from Budapest.  I was born in St. Louis, Missouri.  Does that count as Hungarian?

[hutch--]

These things are about as useful as they work, if it does the job, its worth the effort, if it does not, why bother ? The old Windows convention was useful enough if you understood it so when you had variables like "lpszMyText" you were using a LONG pointer to a zero terminated string. The problem is that they are now DWORD pointers and "dpsz" reads like nonsense so you tend to see "pVariable" as the address of a variable instead.

I normally write data types and structures in upper case ala old C and API code, DWORD, BYTE RECT etc .... but I tend to name variables on how I want to use them and Windows variety hungarian notation often does not suit what I want. In small leaf assembler algos is ceases to matter once you remove the stack frame so it only tends to be useful in mixed higher level code doing API and function calls.

With the macro system in masm32 I use the trailing data specifier "$" for string data as its familiar for people who can read basic but this is only because MASM does not specify this character for any other use so its at least possible to use.

In the long haul, I am basically an epistemological anarchist, if it works, do it, if it doesn't fix it and don't restrict yourself to pat formulas as the results are often not very nice to read.