What do you prepend your class names with?

[TheCPUWizard]

Much Ado About Nothing

Since when has this discussion been about ADO ?

[ovidiucucu]

Since when has this discussion been about ADO ?

ado n. = bustle; fuss; trouble; bother.
Find more about Much Ado About Nothing.

[TheCPUWizard]

My comment was a PUN.
I am well familiar with Shakespeares work. This past summer I attended productions of Mid-Winter's Tale (Hartford, Connecticut), Much Ado about Nothing (Boston, Massachusetts) and The Tempest (Sayville, New York).

[ovidiucucu]

My comment was a PUN.

Well...

[Igor Vartanov]

My comment was a PUN.

Did You mean a Physical Unit Number?

[cilu]

Hey guys, don't pollute the thread with out-of-topic chat.

[KevinHall]

I'm surprised how many people think the "C" has to do with hungarian notation.

[jfaust]

I do not embed type information into any names I use.

Naming things well is one of the most important responsibilities and often one of the most difficult challenges facing software developers. Naming is important to correctly understand the problem being solved as well as the solution presented. The names need to be as close to natural language as possible, and at the same time being both concise and precise. I've fixed many bugs (one yesterday) that came about due to poor naming that resulted in a difficulty understanding the problem correctly.

Embedding names with type information does not add anything. I've never been confused as to whether something is a class or an enum or something else. That problem has never ever come up for me. Embedding type information does, however, take away from understanding because you've now taken another step away from natural language. One of the goals of a high-level programming language like C++ is to be closer to natural language.

One convention I do use is prepending (I don't care if it's a word or not!) all my class members with "m_". It is nearly always important to be able to distinguish between local variables and class variables when examining a piece of code. It is rarely important to be able to distinguish between a bool, and enum, and a const pointer to string.

Jeff

[marsh_pottaye]

I am well familiar with Shakespeares work.

To prepend, or not prepend: that is the question...

[PadexArt]

It is rarely important to be able to distinguish between a bool, and enum, and a const pointer to string.

Lucky you. Imagine you receive 300 MB of source code and you have to examine it. I can guarantee you'll want to spend as little time as possible in browsing the files to learn if code is an int, a bool a string or some user type.

[jfaust]

Lucky you. Imagine you receive 300 MB of source code and you have to examine it. I can guarantee you'll want to spend as little time as possible in browsing the files to learn if code is an int, a bool a string or some user type.

A well named variable can make it obvious: numCols, itemCount, deltaX, itemName, etc. Enforcing hungarian notation on these is not only silly, it's detremental because it inhibits understanding.

After that, the usage often makes it obvious. If you access through a '->' or a '.', it's a class or a struct. If you concat it with words it's typically a string. If you use it in a mathematical expression, it's typically a numeric type.

In the cases where the usage of a variable or the variable name itself doesn't make it blazingly obvious what type it is, it typically doesn't and shouldn't matter.

if( someVal )
...

I don't care what data type it is. The intent is clear. What do I care is it's an empty string, a 0 int, a null pointer or a class that has a cast to bool operator. We are checking for validity.

When you need to go more in depth and you are debugging or changing code, variables will either be declared locally (the more locally the better) or in the class header. If you are making changes, you should be intimately familiar with the area you are changing. The familiarity should go way beyond what type of data it is. You should understand the meaning and the intent.

Jeff

[Igor Vartanov]

I have really no idea why this thread is lasts. People are different. Period.
Each one programmer at the every moment is under the pressure - the pressure of its habits, adopted (willingly or not so) rules, superstitions or explicit orders. Somebody likes to talk about WHY AM I USED TO DO <..> and another one just goes on and tries to do his best. It proves just the only thing: people are different.

BTW: reading the thoughts of yours I did get not a single reason why should I have to betray my own style (whichever it could be). Except the one case - I should obey the company standard (whichever it could be). There's really worthy reason for such exception - they pay me for my job. When fortunately I participate in creation of standard I equip it with the elements (more or less) of my own style without any doubts - when the community approves and adopts them.

"Ogres have layers. End of story. Bye-bye..."(C)Shrek.

[PadexArt]

I don't care what data type it is. The intent is clear. What do I care is it's an empty string, a 0 int, a null pointer or a class that has a cast to bool operator. We are checking for validity.

When you need to go more in depth and you are debugging or changing code, variables will either be declared locally (the more locally the better) or in the class header. If you are making changes, you should be intimately familiar with the area you are changing. The familiarity should go way beyond what type of data it is. You should understand the meaning and the intent.

You must be the luckiest programmer alive. No offense, but it doesn't look that you have ever worked on code written by somebody else. Especially if that code was written in 20 years by more than a single person. Conventions are good and you usually learn this when you struggle to work with someone who doesn't give a heck about them.

[Marc G]

I always prepend classes with C. It makes it much easier to distinguish classes from other things, but well... it's just my opinion

[jfaust]

You must be the luckiest programmer alive. No offense, but it doesn't look that you have ever worked on code written by somebody else. Especially if that code was written in 20 years by more than a single person. Conventions are good and you usually learn this when you struggle to work with someone who doesn't give a heck about them.

One program I work on has code dating from 1965. The other started in 1990. I joined this company in 1997. The vast majority of the code I work on was not written by me. There used to be a naming convention for classes here (an additional 6 letters!) which I obliterated by proper use of namespaces. Yes, I renamed all the classes throughout many hundreds of thousands of lines of code. It was a slow-burn project that lasted 3 years. We do not use hungarian notation and our coding standard explicitly says to not use hungarian notation. I believe our code is the better for it.

Jeff