Out of curiosity, what convention do you use right now?

With this project I am using Hungarian notation though I have modified a few of the prefixes and also added some. What do you typically use?

Ugh, hungarian notation! I hate it [smile], though there are few people who love it, I think.

I used to use it sometime in the past, until I realized it wasn't really adding much to me. In fact, it added nothing. The point behind hungarian notation is encoding a variable's type into its name:
1. This, in theory, would be helpful in loosely-typed languages, not strongly-typed ones like C++. That said, even in loosely-typed languages it isn't practically helpful.

2. If the type of the variable changes, you have to change its name accordingly, and all its references. A very bad idea, unless your IDE comes with refactoring (e.g. VS 2005), in which case it's a bad idea, because it:
(a) Takes a little bit of time (to replace the references)
(b) Requires rebuild (bad in medium and large projects)
(c) Possibly other things I don't know, but they're ugly [grin]

3. The type of the variable should be available from its name AND the context. e.g. When I'm storing geometry IDs, I don't say:
DWORD dwGeometryID;

Instead:
typedef DWORD geometry_id_t;
geometry_id_t geometry_id; // or only id, depending on context

The latter is:
a. More clear
b. If I later decide that geometry_id_t should be a short instead or whatever, I just change the typedef (though I'd still rebuild). Typedefs are really powerful if used correctly, by the way. And they can help you in cross-platform development situations (e.g. The PalmOS has the socket type NetSocketRef, while windows has it named SOCKET,...etc).

There's no reason to name the id dwID or something, because its type is obvious. Generally, when working with a variable, I know its type - A variable never stays alive for a long time without use for me to forget its type. Refactoring and self-documenting code make your functions really specific in what they do, and rather short (see [1]) - meaning you really don't have enough time to "forget" a variable's type in the middle.

4. I prefer my code to look (as much as possible) like pseudo code - as high-level as possible. Types aren't encoded/defined in pseudo-code.

You can really find out a lot of the pros and cons of hungarian notation through google. A quick search gave me [2] as a first result.

Now that I ranted enough about what I don't use, I'll start talking about what I do use [smile]. I generally use the convention of the language I'm working with. If I'm using C/C++/php, I use the underscores_to_the_rescue syntax. I just LOVE IT. I use an additional '_t' to indicate types (Otherwise you wouldn't be able to make an instance of the type foo_bar and name it foo_bar). I love this, because:
1. It looks more like pseudo-code (i.e. an underscore's like a space)
2. It's easier to read when using long function/variable names, which I often do (see [1])

The most common complaints about them are:
1. Harder to type: Not really (to me, at least). But I've been thinking about a little app that'd allow you to select a window, and then convert all Shift+Space or whatever messages directed at the window to underscores (for those who can't type it fast enough). It'd be a nice experiment, I think [smile]

2. Doesn't look good when hyperlinked in documentation (because hyperlinks are usually underlined, and then the underscores don't stand out): I disagree with this, and even if it was true, the benefits would outweigh this (to me).

Bjarne, on his website, uses a slightly different convention. Some_type for types (first letter uppercase). I've not tried it before, but I think it'd work ok.

When I use C#/VBScript, I stick to CamelCase naming for functions, and firstCamelCase naming for variables, because:
1. If you do otherwise, FxCop is going to complain like you've killed his mother
2. That's how the preferred convention for that language

I do prefer the Java naming convention to this one, though, where methods are firstCamelCase too, because object.doSomething() looks more natural than object.DoSomething() to my eyes. But I don't use it.

This stuff is rather subjective by the way, so don't take my word on it. Decide on what works best with you, and keep in mind that you'll work with conventions you don't like anyway when you work with other teams (Unless you happen to be the lead and specify your team's convention to be yours [smile]).

[1] There's a great article series called "The Craftsman" in here that talk about modern practices and test-driven development. Search for "Craftsman" in that page, and start with #1. I believe there are ~26 ones.

[2] Hungarian notation: The Good, The Bad, and The Ugly

Thanks Coder! I'm dumping my hungarian and switching to the type method. I guess yesterday's work goes in the trash. [smile]

I am going to keep an underscore before my private members (_Name) as this seperates them from the public ones when accessing members from an object. Know of a better way? So should I still use the m_Name prefix for members?

Edit: Thanks for the link to "The Craftsman"! I'll read them all.

Quote: I'm dumping my hungarian and switching to the type method. I guess yesterday's work goes in the trash.[smile]

Be careful not to switch to a notation you don't like - this stuff, as you must've known by now [grin], takes time.

Quote: I am going to keep an underscore before my private members (_Name) as this seperates them from the public ones when accessing members from an object. Know of a better way? So should I still use the m_Name prefix for members?

IIRC, identifiers with a leading underscore are reserved for implementation extensions (not exactly sure about what it's reserved for, but it's reserved for something).

That doesn't mean your code will break, it just means an implementation could use that underscore-prefixed name as a keyword (e.g. _asm, _finally) in which case you'd have to change it. Some people use a trailing underscore, but most people I know use the 'm_' prefix. Some people use no prefixes at all. As always, use what suits you best.

Quote: Be careful not to switch to a notation you don't like - this stuff, as you must've known by now, takes time.

Oh I know [smile] I have been at it for the last 10 hours. I'm liking the name_that_looks_like_human_language style much better and my code is already looking much better. Besides that I am adding greater meaning to many of my variable names. The idea that my code could look more like pseudo code really appeals to me. I appreciate your suggestions and wisdom.