News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

asm hungarian notation

Started by thomas_remkus, January 22, 2007, 04:07:09 PM

Previous topic - Next topic

thomas_remkus

In my masm creation I have variables. Is there a Hungarian, or EQU, notation for MASM/ASM? If other programmers read my code I want it to be mostly self documenting and other than descriptive variable names I wanted to know about any standard suffix system.

thomas_remkus

Is there also some standard for white space? Returns between functions I'm guessing ... but what about left white space? I see so many people with different styles. It's a little frustrating. So is there a standard or is the MASM/ASM community just filled with creative tolerance? If so, then I'll need to get some of this too.

Vortex

Thomas,

There is no special standards for MASM coders. You are free to select any notation you prefer. There are members who like the Hungarian notation and others who would avoid it.

Personally, I would vote for the Hungarian notation :U

Tedd

No 'standard' as far as I'm aware (or that anyone else is aware of, judging by others' code :bdg)
If you want it to be readable, I'd suggest avoiding Hungarian notation :P When used correctly it's only useful for those trained in it, and when done badly it looks like jibberish. That said, it's not enirely useless if used minimally. In asm, I tend to prefix parameters with 'p' if they're pointers, but little more than that (if you find you're prefixing with 5 or 6 letters, there's probably something wrong.)
As far as layout goes, you'll eventually find one that suits you. The only real rule is to be consistent - this, more than anything else, will help your code to be readable.
Use whitespace to separate logically separate blocks. And a little more to make functions look separate (i.e. 2-3 lines, instead of just one.) Be consistent with your choice of indentation 'rules.' Use uppercase to separate words in function/variable names...
As long as it makes your code easier to read/follow, then use it. And then be consistent with using it. The judge on readability is yourself :wink
No snowflake in an avalanche feels responsible.

thomas_remkus

LOL !!! This is just awesome. there is such posturing with higher level languages that I, myself, have been battered and battered others on their code "style". It's so awesome to see that asm-ers really understand what they do that they can read each other's code. I hope when I post here more than a few lines of code people will understand me too.

sluggy

Personally i hate hungarian notation - it should only be used in academic institutions so that n00bs learn to code well.

Personally i like to use old school C/C++ syntax, so module level member variables start with an underscore, variables don't have a prefix to indicate what they are (they shouldn't need it if you have named them well!!!!), constants are capitalised, non-private functions start with a capital letter, private functions start with a lowercase letter, function and variable names are camel cased.


Ehtyar

Quote from: sluggy on January 22, 2007, 09:30:01 PM
Personally i hate hungarian notation - it should only be used in academic institutions so that n00bs learn to code well.
Bit rude, but i guess we're all used to that by now.
Quote from: sluggy on January 22, 2007, 09:30:01 PM
Personally i like to use old school C/C++ syntax, so module level member variables start with an underscore, variables don't have a prefix to indicate what they are (they shouldn't need it if you have named them well!!!!), constants are capitalised, non-private functions start with a capital letter, private functions start with a lowercase letter, function and variable names are camel cased.
Never heard of this kind of notation, might give it a try, thank you.

Ehtyar.


GregL

Well, personally I prefer to use Hungarian notation. It's not "in style" and may be frowned upon right now, but it works for me. And it works equally well in any language.

To each his own.  Use what works for you.

Of course if you are working on a group project you probably don't have a choice.


u

I code in the style, mentioned by sluggy. With the addition of an "f_" before struct-members, being pointers to functions. And special bracket-lines (for "whitespace") around parts of code that do different things in a proc


;------[ Control-flags ]---------------------------------------------[
CTLFLAG_NONE equ 0
CTLFLAG_AUTOMATABLE equ 1
;--------------------------------------------------------------------/


ModuleX struct
caption db 32 dup (?)
NumAutomatables dd ?
pIsValAutomated dd ? ; pointer to a  char[NumAutomatables] array, that specifies if a knob is automated. Values are AUTOCTLSTAT_NOT_AUTOMATED,..
;---  functions ---\
f_OnMouse IFUNC(pModule,pCtl,x,y,MouseState)
f_OnPaint IFUNC(pModule,MouseX,MouseY)
;------------------/
ModuleX ends


AutoGraphTool_GetTrackFromPoint proc uses ecx pTW,y ; Zero flag is set on return failure!
cmp y,0
jle _ret
;----[ get total height of tracks ]-------------[
mov ecx,pTW
mov eax,[ecx].AutoGraphTool.AllTracks.BytesTaken
shl eax,5; EAX now has the total height
;-----------------------------------------------/
;--[ exit if cursor is below all tracks ]-----[
cmp y,eax
jge _ret
;---------------------------------------------/
;------[ get hovered-over track ]-----------[
mov eax,y
shr eax,7
shl eax,2
add eax,[ecx].AutoGraphTool.AllTracks.MyData
mov eax,[eax] ; EAX now has the pTrack
;-------------------------------------------/

test eax,eax
ret

_ret: xor eax,eax ; failed
ret
AutoGraphTool_GetTrackFromPoint endp

and nesting them:
...
;------------[ deflate 16->32 ]-----------------------------------------------------------[
.if IsAlpha
mov eax,pSprite
...
nextline:
...
@@:
;---[16->32]--------\
...
;-------------------/
...
dec wid2
jnz @B
sub edi,extraDest
dec hei
jnz nextline
.else
nextline2:
...
@@:
;---[16->24]--------\
...
;-------------------/
...
dec ecx
jnz @B
sub edi,extraDest
dec hei
jnz nextline2
.endif
;-----------------------------------------------------------------------------------------/
...
Please use a smaller graphic in your signature.

Shantanu Gadgil

Hi,
I use the Hungarian notation too. Kinda like it...or have too used to it, so like it! :)

Anyway, one thing I have "ripped" from C++ style guidelines is the use of "m_". C++ has a convention of using "m_XXX" for member variables. I do that for variables that I would require only in a single file ('static' in C). If many functions are sharing a variable among them, and if I don't require the variable outside that particular file, I name is "m_XXX".
I generally let variable names be default Hungarian "hFile", "hWnd" inside a function.
Also I do use "g_" for variables which I might have to keep visible across all the modules that i have.

Cheers,
Shantanu
To ret is human, to jmp divine!

stanhebben

I sometimes use hungarian notation in assembly or C, to make definitions clearer. In C++, D and Java I don't use it at all.

sluggy

Quote from: Ehtyar on January 22, 2007, 10:02:36 PM
Quote from: sluggy on January 22, 2007, 09:30:01 PM
Personally i hate hungarian notation - it should only be used in academic institutions so that n00bs learn to code well.
Bit rude, but i guess we're all used to that by now.
Heh, not rude, just honest  :bdg
Let me explain a little about my choices.

No prefixes before variable names ('obj' in 'objSomething' to say it is an object): this only has a use in scripting or interpreted languages. In languages like C/C++/C#/VB/VB.Net/MAMS/etc etc, they have compile time checking to ensure that there are no type mismatches, which makes prefixing the variables rather redundant - you only put the prefix on to remind yourself what should be assigned to it. And when you type hundreds to thousands of lines of code a day, putting prefixes on your variables means a lot more typing.

Using underscores in front of member variables: when using an IDE that has full intellisense, these variables end up grouped at the top of the intellisense dropdown - this is very handy. By putting an 'm' in front of them, they would end up halfway down the list in the M section, and with the grouping most likely broken up by other properties/functions starting with 'm'. Incidentally, i believe the habit of prepending 'm_' on the front of variables was started by MFC coders - that was how a lot of the samples from MS were done, so everyone copied it. Using only underscores in front of those variables also has another benefit - it makes your code easier to read when using a small font, because your eye skips over it quite naturally and it looks like a space, which helps break up lines of dense code. Here is a bit of made up code to illustrate this point:

int x = doSomeSpecialWork(this._application, getWeekCommencing(Datetime.Now), calculateInterest(_account, interestRate, calculateTimePeriod(_lastCalcDate, DateTime.Now)));

and this is how it would appear without the underscore and with the IDE automatically spacing things:
int x = doSomeSpecialWork(this.application, getWeekCommencing(Datetime.Now), calculateInterest(account, interestRate, calculateTimePeriod(lastCalcDate, DateTime.Now)));


and this is how it would appear using hungarian notation:
int x = doSomeSpecialWork(this.mobjApplication, getWeekCommencing(Datetime.Now), calculateInterest(mstrAccount, decInterestRate, calculateTimePeriod(mdateLastCalcDate, DateTime.Now)));


You may or may not appreciate the difference between these three examples, but when you are reading stacks of lines like these, having a little extra (apparent) space is convenient - not to mention the bonus of knowing instantly that we are dealing with some module level member variables when using the underscore. The longer something takes to read, or the more times you have to reread it to understand it, the longer it takes to do your job, and the more chance you have of making a mistake.

Using upper/lower case first letter in function names: this is an instant indicator of whether the function is private or public (or protected, etc). Once again, this is very useful when reading dense code or looking at intellisense lists.

Of course you are all welcome to debate these opinions  :lol  I am a software engineer and architect and i find they work for me when coding for 8 to 10 hours a day - but they may not suit everybody  :8)





Ehtyar

Thank you for the explanation, though you may have been a bit more tactful earlier, remember half this forum most likely uses hungarian notation, and very few of us are "n00bs".

Ehtyar.

gabor

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

Shantanu Gadgil

Its called so coz a person called Charles Simonyi came up with the idea, and he is Hungarian.

Its mentioned in the Charles Petzold's book or you could just check it here:
http://en.wikipedia.org/wiki/Hungarian_notation
http://en.wikipedia.org/wiki/Charles_Simonyi

Cheers,
Shantanu
To ret is human, to jmp divine!