Naming conventions for ASP.NET objects?

[=B=]

Hi,

I was wondering if anyone has any opinions on naming conventions for
ASP.NET objects?

Up until now I've been using txtThis for Text Boxes, ddlThat for
DropDownList, etc because I think it helps the readability. When
working with a code-behind file you can tell what type of object
you're accessing. Of couse, this Hungarian notation is frowned upon
by the Microsoft guidelines for classes at
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp
and FXCop complains about 'txt' not being a word, etc.

How does everyone else name their web controls?

Thanks,

B.

 

[Peter Rilling]

That is how I do it also.

 

[Scott M.]

When you read that MS frowns on Hungarian notation for classes, they are
talking about just that the class name, not the instance name.

I think you will find that the use of naming notations with controls is
still very much alive (remember a control that you use on your form is not
the class (TextBox), but an instance of a class (txtUser).

 

[Karl]

I follow FxCop (and therefore microsoft guidelines). Hungarian notation is
frowned upon...and, unlike what Scott said, it's not just for class names
but everything (instances, fields, proeprties...). The reasoning behind
this, as I understand it is two-fold:

[a] - leverage your tool's ability to know what type it is (ie, buy vs.net
*$$$$*)
- a far better reason is that your code should be properly refactored
and as such, should never be so complex that someone needs to know what type
of variable is. In other words, readability comes from proper design and
not any metadata you can stuff into a variable's name.

if you name your variables That and This though, hungarian notation might
not be such a bad idea

Karl

 

[=B=]

Thanks for all the responses, guys. And Karl, in retrospect maybe
those variable names weren't the best examples...

I do actually use VS.NET. It's just that coming from an Interdev
background onto ASP.NET I guess it's a force of habit more than
anything else to use prefixes for control IDs. Should I be using
camel case instead?

A problem with this though is that if I have a TextBox control called
'userId' and perhaps I need String which I use to hold the contents of
this TextBox, I can see situations where following Microsoft's
guidelines (or what I perceive to be them) on this issue could cause
confusion. Distinguishing between the control and the string variable
by giving them different variable names, e.g. calling the TextBox
userIdTextBox, I'm still storing the object type in the variable name.

I'm studying for my 70-305 exam and it doesn't help matters that all
the examples in the MS book so far seem to use Hungarian notation!

B.

I follow FxCop (and therefore microsoft guidelines). Hungarian notation is
frowned upon...and, unlike what Scott said, it's not just for class names
but everything (instances, fields, proeprties...). The reasoning behind
this, as I understand it is two-fold:

[a] - leverage your tool's ability to know what type it is (ie, buy vs.net
*$$$$*)
- a far better reason is that your code should be properly refactored
and as such, should never be so complex that someone needs to know what type
of variable is. In other words, readability comes from proper design and
not any metadata you can stuff into a variable's name.

if you name your variables That and This though, hungarian notation might
not be such a bad idea

Karl

Hi,

I was wondering if anyone has any opinions on naming conventions for
ASP.NET objects?

Up until now I've been using txtThis for Text Boxes, ddlThat for
DropDownList, etc because I think it helps the readability. When
working with a code-behind file you can tell what type of object
you're accessing. Of couse, this Hungarian notation is frowned upon
by the Microsoft guidelines for classes at
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp
and FXCop complains about 'txt' not being a word, etc.

How does everyone else name their web controls?

Thanks,

B.