PocketMatrix

<br>Here is the link if anyone wants to buy it, or just look at it's details. It seems like quite a nice book. It's too bad I have so much time on my hands, which everyone tries to make me use their way so I don't have any time to do what I want anymore.<br>

I have no idea why this thread insists on being "New!"

well its not. Boy i wish i could post html here. but that will have to wait...

Probably because i modified that last post there. I should really go in there and fix that bug, since Chris and Matt are too ignorant in the ways of Perl. But that involves work, and investigation, and reading... None of which suit me well.

Not gonna make friends today.<br><br>Dan.  Nice list, but I have a problem with<br>LPTSTR pszName;<br>TCHAR  szAddress[256];<br><br>BOTH are pointers.  I typically use sz in either case, since it is more indicative of use than datatype.<br><br>n for int....what happened the old stand-by of i?<br><br>And p for pointer is ok, but I am a bad boy from the old school who still uses lp.<br><br>m_  EVERYONE should do this...glad you said it too.<br><br>MooseMaster...the book is great.  I have a copy that I think I wore the ink off of.  ALSO GREAT BOOKS.<br><br>Anything by Knuth.<br>Writing Solid Code.<br>Code. (I forget who it is by, but it has everything about bits and bytes and switches you can imagine.  He starts out with creating a basic switch from an iron rod and some coil...heheh)

Wow, I'm surprised people are reading my posts that are 1.5 years old. I've updated the tags for the current php BBS software.

Dan East

Hungarian notation has both advantages and disadvantages.

1) It has the general advantages of having a naming convention.
2) It serves to document types in a weakly typed language. This doesn't apply as much for C++ as it does for C.

But Hungarian has serious drawbacks:

1) Hungarian ignore the use of abstract data types as base types. Because of this, it forces programmers to worry about manual type checking instead of letting the compiler check the types more rapidly and accurately.
2) It combines data "meaning" with data "representation". This is so bad, I don't even know where to start.
3) It encourages lazy, uninformative variable names. (ie: "hWnd" vs "MainMenuWindow").

These ideas are taken directly from "Code Complete" mentioned up there, and I totally agree with the author's point of view. Hungarian simply sux. It isn't all that bad when programming in C, but it is a real problem when dealing with C++. It encourage slopiness in the architecture. If you want a good example of a crappy architecture, look no further then MFC. It's an old library that was written before C++ had a standard. I am not saying MFC wasn't good when it came out, it is simply a product of it's time.

Now prefixing all class names with "C" or even "T" or whatever is not that bad, although I prefer to start my type definitions with an uppercase letter. This way, the prefixing is not needed.

To anyone who will argue that having the type described as a prefix "pwstr" is useful because you don't have to go check the type of a variable when you use it: that's exactly why prefixes shouln't be used. To me, "playerName" is infinitely more clear then "pszname", and "pszPlayerName" is not adding anything. It even become a problem when I change my variable to a "std::string".

Sorry, I didn't look at the date. I'm new to the board and was just reading through the posts.