I still maintain my old C style after all these years (even in C++). When I start a project, I'll take the first two letters of the name and make that my prefix. After that, it is the "ol' way of doing things."

void ge_foo_bar( void* foo, const unsigned int bar );

I've simplified to the essentials over the years. I prefix for interfaces, cause C# still rolls that way and I like it. (Non-pure abstract base classes are suffixed with Base, usually.) Single underscore to label _private or _protected class variables*. And g_ for globals because those should look gross. That's pretty much the extent of it.

* The underscore thing also works great in languages that don't HAVE private scoping, or when I don't actually private scope them but they're considered implementation details.

I follow this kind of minimalist approach as well. Prefixing classes with C, or variables with their atomic type, or similar things doesn't really tell you anything useful with modern tooling. Even people who work with text-mode editors like emacs or Vi(m) will have CTags or some kind of IDE-like intellisense-thing going on.

Scope is still something helpful to know so I do 'g_' prefixes for globals and 'm_' (or sometimes, just '_') prefixes for private/protected members. I also like to know things like whether a variable is static or volatile at a glance, so I use 's_' and 'v_' prefixes there -- these are rare though.

As far as general naming, I use plural word-forms when dealing with collections of things, and boolean variables/functions are almost always prefixed with a word like 'is' or 'has' to reveal the question being answered -- like 'is_dead' or 'has_children()', among other things similar to what DonaldHays quotes above.

In C++ (as are all of my examples above), I defer to my own personal axiom of "do as the standard library does" regarding naming and other externally-visible conventions. For example, this is the reason I now use lower-case-with-underscores style, rather than CamelCase or pascalCase as I did at different points in the past. When I'm doing C#, my naming conventions follow the style of its standard libraries. My rationalization for why this axiom of mine is a good approach is that 1) these standard libraries represent the only style that has any credible claim that it "should be" the universal style, and 2) they've seen every odd corner case and combination thereof, and have laid down an answer; I don't have to waste brain-cells thinking it through and then being self-consistent on each rare occasion it comes up, months or years between.

Of course, if the place that makes sure your paychecks don't bounce has a house style -- and most do -- then you follow along with that because its part of what you're paid to do.

I prefix everything with a C except for classes; just to keep people on their toes. At least that way if it doesn't start with a C then I know it's a class :rolleyes:

Seriously though, just encode useful information into your symbol names and you'll be good - I (like most people I suspect) don't actually find it useful to re-encode whether something is a class or not.

So I don't bother prefixing C - I will however attach prefixes for semantics that aren't captured by language's type system...

e.g. cameraPos, cameraAngle, cameraZoom, cameraEnabled

e.g. screenWidth, screenHeight

e.g. warningText, warningColour

...but lately I've been experimenting with an underscore in front of non-public declarations.

This one makes sense to me. I can understand a prefix on non-public stuff and having such a consistent prefix works well with autocompletion.

The idea has mostly fallen out of favour these days, but that's where it came from.