Naming Conventions

http://support.microsoft.com/kb/110264
Talks about naming conventions for Visual Basic.
What are the naming conventions for C++

If I have a resouce ID for a menu, should it start with IDM_ ?

Read the bottom of that page:

Microsoft wrote:

•	Microsoft Visual Basic 4.0 Standard Edition
•	Microsoft Visual Basic 4.0 Professional Edition
•	Microsoft Visual Basic 4.0 Professional Edition
•	Microsoft Visual Basic 4.0 16-bit Enterprise Edition
•	Microsoft Visual Basic 4.0 32-Bit Enterprise Edition
•	Microsoft Visual Basic 2.0 Standard Edition
•	Microsoft Visual Basic 3.0 Professional Edition
•	Microsoft Visual Basic 2.0 Professional Edition
•	Microsoft Visual Basic 3.0 Professional Edition

You're going to have to do what your department wants you to do, but that said:

I like to be as descriptive as possible.  If it takes 30+ characters to desribe a boolean flag, I'll take that many.  And I

LOOOOOOOOOOOVE

Camel notation with the type in front

i.e.

cbThisMeansThatTheSystemIsBroken

is a combobox that allows someone to decide that the system is broken

Of course, that's just me

complete wrote:

http://support.microsoft.com/kb/110264
Talks about naming conventions for Visual Basic.
What are the naming conventions for C++

If I have a resouce ID for a menu, should it start with IDM_ ?

IAgree. Although IThink the Java/Ruby/... notation of lower-case method names is not bad either.

While it is true that Hungarian type is decades old, and using it in a strong typed language where vars can be cast back and forth into different types (if strX is now an int type that "str" is useless of course), I still like to use it outside of classes in ASP.NET UI instances.

Case in point: I might have a section on a form that gets information from the user regarding, I dunno, what kind of car they have. I might have a txtCarInfo field, information returned to the UI from the backside might be displayed above that field in a lblCarInfo label. Maybe there is a btnCarInfo.

If its an object that is bound to in the code behind to a datasource maybe I have a dtCarInfo. Personally, I just find its easier to break up logical descriptions of complicated forms. And this is really a poor example. I also like to be detailed as possible so, the vars and not just my commenting make life easier for subsequent developers.

If you do not develop a lot on the backside, you can also think of it in terms of good CSS class/id naming conventions. For instance, .left_text_box is not a good name because what happens when its moved to the right side in the UI? Web standards guys are always raving about "semantic markup" but the semantics of your naming convention is a universal issue. Writing readable and user friendly code is all about semantics.

W3bbo wrote:

Read the bottom of that page:

Microsoft wrote: • Microsoft Visual Basic 4.0 Standard Edition • Microsoft Visual Basic 4.0 Professional Edition • Microsoft Visual Basic 4.0 Professional Edition • Microsoft Visual Basic 4.0 16-bit Enterprise Edition • Microsoft Visual Basic 4.0 32-Bit Enterprise Edition • Microsoft Visual Basic 2.0 Standard Edition • Microsoft Visual Basic 3.0 Professional Edition • Microsoft Visual Basic 2.0 Professional Edition • Microsoft Visual Basic 3.0 Professional Edition

This doesn't apply to VB.NET, the article makes heavy use of Hungarian, which is decades old.

You should use naming convention that as closely as possible resembles the thing that it is not, for example, if you are storing someones' username, call it intPswdHash or boolActive.

Seek where possible to use names that are unpronouncable such as QWFD, and seek to name variables using words or symbols to enhance the "prouncive flow" of the statement, and make deliberate misuse of the #define directive, for example

#define STRING 4
#define new 1 +
int STR = new STRING();   STR is now set to 5.

Some companies require you to name "magic numbers" that you use throughout your project. Do so; for example, the code

int magicNumber = 4

is wrong! Use the following:

#define MAGIC_NUMBER 4
int magicNumber = MAGIC_NUMBER;

or, preferably,

#define THREE 4
int magicNumber = THREE;

With a view to helping your coworkers who may be required to maintain your project, make liberal use of words which obtain meaning from a social context. The compiler does not care about such "labels" and therefore the maintenance worker will see no problem with sharpening his skills in this area. Indeed, he may thank you for it. For example;

int N = ( (magic / sparkles * GOD / superman) << Adolph ) | Eichmann


Alternatively, choose names designed to ensure that the statement cannot be said over a telephone call, thus not allowing the FBI and/or competition to find out the inner workings of your company secrets:

int times = (divide_over / (plus++) << shift | right) + plus

And remember, if worst comes to worst, remember good ol' underscore; he is your friend.

#define _ 1
#define [ 0
#define ] <<

int zero = [
int one = _
int two = _]_
int three = _]_|_
int four = _](_]_)
int five = _](_]_)|_
int six = _](_]_)|(_]_)

etc.

Randolpho wrote:

Personally, I very much prefer the C# naming convention, which is PascalCase for everything and prepending I for an interface (i.e. IDisposable).

TommyCarlier wrote:

IAgree. Although IThink the Java/Ruby/... notation of lower-case method names is not bad either.

I do the same as littleguru except I also put a _ in front of it (I use that for all private fields), so it'd be _carInfoTextBox in my case.

And also like littleguru I don't put the type into regular variable names.

Sven Groot wrote:

I do the same as littleguru except I also put a _ in front of it (I use that for all private fields), so it'd be _carInfoTextBox in my case.

Sven Groot wrote:

And also like littleguru I don't put the type into regular variable names.

I prefix class fields with f and local variables inside a method with l (EL). This means I rarely have to use the "this." specifier. It's always clear that x is a method argument, fX is a field and lX is a local variable.

Whichever naming convention you choose, make sure that it doesn't depend on case sensitivity.  Some .NET languages (VB.NET in particular) are case-insensitive.

Yay! Everyone seems to be taking my idea of underscore prefixing really seriously - W3bbo even seems to have specific numbers of underscores to increase the semantic meaning of his variables.

Eat boot, ye gods of standarisation! Obfuscation and mayhem FTW!

evildictaitor wrote:

Yay! Everyone seems to be taking my idea of underscore prefixing really seriously - W3bbo even seems to have specific numbers of underscores to increase the semantic meaning of his variables.

• Do not use Hungarian notation
• Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.
• Do use camelCasing for member variables
• Do use camelCasing for parameters
• Do use camelCasing for local variables
• Do use PascalCasing for function, property, event, and class names
• Do prefix interfaces names with “I”
• Do not prefix enums, classes, or delegates with any letter