Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


hungarian notation for a float and a structure

This topic is 5965 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

You probably won''t find anything as MS has been moving away from Hungarian notation. That said, for float, prefixing the variable name with ''f'' should do it. For structures, it probably depends on whether you''ve typedefed them or not. MS doesn''t use any specific notation to indicate them. In other sources I''ve seen "_t" appended to indicate a type.

Share this post

Link to post
Share on other sites
Original post by LessBread
You probably won''t find anything as MS has been moving away from Hungarian notation.

MS has moved away from it???

Share this post

Link to post
Share on other sites
MS no longer uses hungarian notation in DX at least, although I don't know about their internal policy.

To be honest, I'd be glad to see the back of it. In the event that your code is sufficiently badly organized and convoluted that you cannot easily see what type a given variable is, most half decent IDE's will tell you what type a variable is just by hovering the mouse over it. So I don't really see the point in attaching huge ugly hungarian warts to every variable, obfuscating the actual meaning of the variable and making it harder to type.

Of course this is just my personal opinion. In less strongly typed languages, some sort of variable type naming might be useful.

From How to write Unmaintainable Code

Hungarian Notation: Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.
Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.
Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated: if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!
Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.
Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!
Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:
a single assignment statement carries 14 pieces of type and name information.
a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.

Hungarian Notation Revisited: One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

[edited by - Sandman on March 20, 2002 8:17:22 AM]

Share this post

Link to post
Share on other sites
Personally I use the following for work work. For homecoding I am less rigorous as only I play with my code.

typedef struct MyStruct_s
float m_fMyFloatStyle;
int m_iMyIntStyle;
unsigned int m_uiMyUnsignedIntStyle;

For other types I use the suffix of _c for classes and _e for enumerated types. While not quite hungarian it gives you all information you need to know by just looking at the variable names.

Stay Lucky, Graham "Mournblade" Reeds,
ICQ: 30514803

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!