Archived

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

Shambles

object notation

Recommended Posts

Shambles    122
Can someone link me to a resource which contains a full list of common object notations? (such as b for bool, p for pointer, I for interface and so on...)

Share this post


Link to post
Share on other sites
-Thork-    139
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.

Share this post


Link to post
Share on other sites
ShawnO    145
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]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
carefully consider whether you want to even do this

Share this post


Link to post
Share on other sites
Shambles    122
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.

Share this post


Link to post
Share on other sites
Oluseyi    2112
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.

Share this post


Link to post
Share on other sites
Shambles    122
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 -".

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Fruny    1658
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.

Share this post


Link to post
Share on other sites
Oluseyi    2112
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.

Share this post


Link to post
Share on other sites