object notation

Afaik, there is no certain ''defined'' set. There are common practices, such as suffixing lp or p for pointers. As for a site that lists them, I couldn''t tell you, but I''ll give you a few common ones (some of thes may just be ones that I made up - I have a bad memory )

dw - DWORD w - WORD
b - bool i - integer
lp / p - pointer sz - string (typically char)
C - class I - interface
h - any handle (HFILE, HANDLE, HMODULE, etc.)
f - float l - long

That''s all that spring to mind at the mo.

For a description of hungarian notation take a look at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp
Search for "hungarian notation" on Yahoo for a bunch more links.


[edited by - ShawnO on October 1, 2002 12:46:38 PM]

Thanks for the replies guys.

Anonymous Poster: I''m not going to actually implement it in my projects just yet. Its just that many projects use hungarian notation and although some seem obvious such as p, others comfused me.

With modern tools and environments, there is little need for name warts. Hungarian notation and other wart schemes that try to indicate object type are rendered completely useless by the most basic IntelliSense features of MSVC and other IDEs (tool tips that indicate object/variable type).

The only arguable case for name warts is to convey contextual information such as the units of a quantity, etc. Magmai Kai Holmlor has on more than one occasioin pointed out the NASA programming error where one programmer though a quantity was expressed in pounds per square foot or so, and the other thought it was in Newtons (resulting in applications of incorrect formulae and the eventual crash of a rocket).

One big argument against name warts is that they become a hassle to maintain as a project grows: you initially store a value as an integer and name it iValue. You later alter it to floating point and then need to alter all references to it in the code. "Easy," you might say. "Just use the replace functionality of any modern IDE." What happens when you name a typedef or other form of alias according to its original base type, widely deploy a library using the type and then need to alter the type definition - say to accomodate with migrating to new word-size platforms? Then you have the puzzling case of the Win32 API, where WPARAM and LPARAM, for instance, are now the same size.

Don''t do it. It serves no useful purpose any more.

Again, I never said I wanted to implement it! I just thought it was something nice to know. The only type of notation I use describes how a variable is used such as: ''nObjects'' The total number of objects in a array called ''Objects[]''. Instead of a notation of type, it can be thought of "number of -".

quote:

---

Original post by Shambles
The only type of notation I use describes how a variable is used such as: ''nObjects'' The total number of objects in a array called ''Objects[]''.

---

That''s descriptive variable naming, and is a Good Thing™!

quote:

---

Original post by Oluseyi
Don't do it. It serves no useful purpose any more.

---

I have to politely disagree with Oluseyi. I believe that Hungarian notation can be very useful, and I use it all the time. I like being able to look through my code and instantly know what type a variable is, even months after the code was written. The delay between moving your mouse over the variable and waiting for the intellisense tooltip to appear may be small, but the delay for my eyes to identify 'pObject', 'nNumObjects', or 'strObject' is nearly zero.

-Mike

[edited by - doctorsixstring on October 2, 2002 10:36:08 AM]

pObject I can understand. But why have a ''n'' before nNumObject ? Isn''t ''NumObject'' already implying you have a number ? And what of ''strObject'' ? Is it the object''s name ? Type ? Description ?

As for unit types :

class Force
{
public:
   double inPound() const { return f*0.2248; }
   double inNewton() const { return f; }
   
   Force& inPound( double value ) { f = value/0.2248; return *this ; }
   Force& inNewton( double value ) { f = value; return *this; }
private:
   double f;
};
 

The access methods imply the units used and avoid errors.

quote:

---

Original post by doctorsixstring
I have to politely disagree with Oluseyi.

---

While you are, of course, free to, I think you are mixing up notations that convey type and notations that convey use. pObject (or object_ptr, or any other variation) is a usage notation: "this is a pointer." I endorse and encourage such use, since it provides additional information. Same with num_objects. But nNumObjects is redundant since an object count is almost always a form of integer anyway (unless you could have 2.5 objects, but then you''d probably have a different name for it).

Note that pObject doesn''t indicate what type of pointer it is (ie, pointer to what - an "Object"?) More often than not, descriptive variable naming solves such problems.

By the way, Hungarian notation was originally developed for use in assembly language programs where variable names were limited. Having a mnemonic scheme to indicate the "type" of a variable was very useful then, as descriptive variable names were largely impossible.