Naming Conventions in C#

Question

As a beginning programmer, I'm trying to settle on a standard naming convention for myself. I realize that it's personal preference, but I was trying to get some ideas from some of you (well a LOT of you) who are much smarter than myself.

I'm not talking about camel notation but rather how do you name your variables, etc. IMHO, var_Quantity is much more descriptive than Q or varQ. However, how do you keep the variable from becoming too long. I've tried to be more descriptive with naming my controls, but I've ended up with some like "rtxtboxAddrLine1" for a RadTextBox that holds address line 1. Too me,that is unmanageable, although it's pretty clear what that control is.

I'm just curious if you have some guides that you follow or am I left up to my own devices?

Answer 1

The more descriptive the better, you will find that the length isn't as important as remembering what that control/variable did five years down the road.

Answer 2

There are a few good coding standards documents available online - David Lance wrote one: http://weblogs.asp.net/lhunt/attachment/591275.ashx

Answer 3

Some basic rules can be found here. And much more extended rules can be found here. These are the official guidelines from the Microsoft framework designers.

As for your example, the variable should should be called simply quantity.

Answer 4

For .NET API design (and some general C# guidelines) check Krzysztof Cwalina and Brad Abrams' Framework Design Guidelines

Regards, tamberg

Answer 5

I'd recommend that you use Microsoft's own guidelines as a starting point. Typically, most companies start there (in my experience, anyway).

http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx

Answer 6

In this case, I think you'd be better off naming it as primaryAddressLine or firstAddressLine. Here's why - rtxt as a prefix uselessly tells you the type. Intellisense will help you with the type and is immune to changes made to the actual object type. Calling it firstAddressLine keeps it away from the (poor) convention of using 1, 2, 3...on the end of variable names to indicate that for some reason you needed more of them instead of a collection.

Name it for what it represents/how it's meant to be interpreted or used not for its data type, and in naming it don't abbreviate if you don't need to.

Answer 7

I generally try to follow the microsoft guidelines, with a few very old habits thrown in.
So, I still can't get out of the habit of prefixing privates with an underscore _privateMember.
I'm old, and that got burnt into my brain.

As far as prefixing control widgets, I have found that if you get too descriptive, it can become painful, in the case of changing the UI down the track.

e.g. you have something called ddlProductLine for a dropdown list, and then that has to change to a radio button group, your prefixing convention starts to be more PITA than helpful.

When you have a lot of widgets to work with, sometimes a more generic prefix like uiCtl can help with the clutter, but still make sense if you have to change widget type.

Answer 8

I like this document:

C# Coding Standars for .NET (zip)

It's a good compilation of best practices and coding style guidelines.

Answer 9

The Guidelines for Names is the best starting point. But as in other areas of life, once you know the rules, you begin to know where it's reasonable to break them.

I never use the old Hungarian notation that calls things strFirstName, intCount, and the like; but I still use it on controls: txtFirstName, btnVerifyData, etc. Reasons include:

• I'm not that likely to change the type of a control
• If I do change the type of a control, I'll have to change a lot of things, not just the name, so changing the name too is no big deal
• They're far easier to find with Intellisense.

In addition, I'm quite likely to do the same thing to many of the TextBoxes or ComboBoxes on a page or form, whereas I'm not likely to do something to all the ints or strings referred to on a page or form. So it helps to be able to quickly find all the TextBoxes with their txt prefix.

There are others, though, that adamantly oppose Hungarian even in this case, and I'm sure they have their reasons. Regardless of your personal style, you may find yourself working on a team that has a very different style. In which case, just do what they do; it's very, very rarely worth making an issue of it. The only time I'd do so is if their style leads to a lot of bugs, but off the top of my head I can't think of a case that would cause that.