Using underscores in type names

[Accutrol]

Huh?

In VB.NET 2003 (.NET 1.1), I created an application that generated an
error after converting to .NET 2.0.

I created two forms, Set_Test_Volts and Test_Volts, in the same
namespace. .NET 1.1 had no complaints.

I converted my application to .NET 2.0. VB.NET 2005 complains:

Error 1 'Test_Volts' has the same name as another type exposed in a 'My'
group. Rename the form or its enclosing namespace.
C:\WindowsApplication1\Form3.Designer.vb 2 15 WindowsApplication1

You can do this, too. You'll get the same result.

If I rename Set_Test_Volts to Get_Test_Volts I get the same error.
But if I change Set to anything else, it reports no errors.

I would really like to not have to change the names of my forms (I use
..NET Reflection to access the form by name from a long list of test
sequences).

Is this a bug? What can I do to work around this issue without
renaming either of the forms?

Thanks for any help,
Hamilton Woods

 

[Armin Zingler]

Huh?

In VB.NET 2003 (.NET 1.1), I created an application that generated an
error after converting to .NET 2.0.

I created two forms, Set_Test_Volts and Test_Volts, in the same
namespace. .NET 1.1 had no complaints.

I converted my application to .NET 2.0. VB.NET 2005 complains:

Error 1 'Test_Volts' has the same name as another type exposed in a 'My'
group. Rename the form or its enclosing namespace.
C:\WindowsApplication1\Form3.Designer.vb 2 15 WindowsApplication1

You can do this, too. You'll get the same result.

If I rename Set_Test_Volts to Get_Test_Volts I get the same error.
But if I change Set to anything else, it reports no errors.

I would really like to not have to change the names of my forms (I use
..NET Reflection to access the form by name from a long list of test
sequences).

Is this a bug? What can I do to work around this issue without
renaming either of the forms?

My.Crap has been introduced in VB 2005. You can disable it:
Project properties -> Compile tab -> Advanced compile options ->
In the "user defined constants" textbox, enter: _mytype="empty"
Let's hope the converter doesn't rely on it in other locations.
I could test it only in a small project and it worked.

Oh,, I've been using VB 2008. Don't know how it works in 2005.

 

[Armin Zingler]

I forgot the explanation:
Internally, a class called "MyForms" inside the namespace "Yourapplication.My.MyProject"
is created. It has one property per Form. Each name is equal to the class name of the Form.
Property set/get methods are internally prefixed by "set_"/"get_". Therefore,
there are the properties

- Test_Volts
- Set_Test_Volts

and the methods

- set_Test_Volts
- get_Test_Volts
- set_Set_Test_Volts
- get_Set_Test_Volts

that would have to be all members of the "MyForms" class. As you can see, the property name
"Set_Test_Volts" and the method name "set_Test_Volts" create the conflict you are seeing.

 

[Accutrol]

So, where's the crystal ball that enables me to see how to avoid
collisions with future Microsoft changes? This reminds me of having
to rename my "C:\users\" folder when I moved to Windows Vista.

Any suggestions on what I can do to keep from renaming my existing
forms?

Thanks,
Hamilton Woods

 

[Armin Zingler]

So, where's the crystal ball that enables me to see how to avoid
collisions with future Microsoft changes?

Naming a Form class Set_* is probably very very rare. Therefore this kind
of collision.

This reminds me of having
to rename my "C:\users\" folder when I moved to Windows Vista.

Any suggestions on what I can do to keep from renaming my existing
forms?

Is using _mytype="empty" not an option for you?

 

[Scott M.]

So, where's the crystal ball that enables me to see how to avoid
collisions with future Microsoft changes? This reminds me of having
to rename my "C:\users\" folder when I moved to Windows Vista.

Any suggestions on what I can do to keep from renaming my existing
forms?

Thanks,
Hamilton Woods

It may not help with your existing code, but using underscores as a type
naming convention has largely fallen out of favor in recent years. Instead,
using camelCase for private/internal names and PascalCase for public names
is recommended.

-Scott

 

[Accutrol]

_mytype="empty" in Visual Studio.NET 2005 produced many errors.

camelCase, huh? Well, I used underscores because I present the
names of the test functions (which are synonymous with the class
names) to the user in a test sequence editor. I just instantiate an
object of the type selected by the user.

I have heard of style guides for naming conventions, but I did not
realize that these had the same force as speed limit signs. I
thought it was just for ease of following one another's coding
conventions. I have never heard of restrictions on choosing
names for classes, objects, variables, methods, properties,
enumerations, structures, etc., other than stay away from
reserved words. I was not aware that name collisions could
occur based on appending stuff to a name.

Lacking any other input, I will build a map of My_Name to
className and rename all of my test function classes to
className convention. Then I can perform a lookup from
My_Name and return className and then use Reflection
on className.

Thanks for your input,
Hamilton Woods

 

[Peter Duniho]

_mytype="empty" in Visual Studio.NET 2005 produced many errors.

camelCase, huh? Well, I used underscores because I present the
names of the test functions (which are synonymous with the class
names) to the user in a test sequence editor. I just instantiate an
object of the type selected by the user.

There's nothing wrong with the underscores per se. It's just that since
VB.NET auto-generates class members using the same "set_..." template
you used for your type name, _and_ because VB.NET is case-insensitive,
you get the collision, _and_ because you happen to have a type name that
looks like the setter method name for another type name you've declared.

It really is a very unusual and unlikely coincidence, as Armin pointed out.

And for what it's worth, if you don't like a language auto-generating
names in your code that might collide with the names you've chosen, you
should probably not be using VB.NET. Fundamental to the way it works in
providing implicit access to certain kinds of objects (e.g. default
instances of your Form subclasses) is to create the potential for these
kinds of collisions, however rare they may be.

There are a number of other languages suitable for use with .NET. Of
course, each of those may have features that also may cause confusion or
frustration. That's just part of learning new languages.

I have heard of style guides for naming conventions, but I did not
realize that these had the same force as speed limit signs.

They don't. Certainly, had you avoided the use of underscores in your
type names, you wouldn't have seen this problem. But it really is just
an unusual conjunction of a variety of factors that caused this. The
underscores per se aren't really the problem.

I thought it was just for ease of following one another's coding
conventions. I have never heard of restrictions on choosing
names for classes, objects, variables, methods, properties,
enumerations, structures, etc., other than stay away from
reserved words. I was not aware that name collisions could
occur based on appending stuff to a name.

In VB.NET, because it is auto-generating class members for you, based on
types you've declared yourself, you have additional potential for name
collisions. Again, this isn't about coding conventions per se. In
fact, in some sense this is just a variation on the rule "stay away from
reserved words". That is, the setter method is always called

Lacking any other input, I will build a map of My_Name to
className and rename all of my test function classes to
className convention. Then I can perform a lookup from
My_Name and return className and then use Reflection
on className.

Note that if you follow the convention suggestion your new class name
will be "ClassName", not "className". In the .NET convention,
camel-case (the latter) is used for variables and arguments, while
Pascal-case (the former) is used for type names, method names, and
property names.

Pete

 

[Armin Zingler]

In VB.NET, because it is auto-generating class members for you, based on
types you've declared yourself, you have additional potential for name
collisions. Again, this isn't about coding conventions per se. In
fact, in some sense this is just a variation on the rule "stay away from
reserved words". That is, the setter method is always called
"set_<typename>" so you should not be making any types or other
potentially colliding names that follow the same pattern.

Yes, just like the following code which is another example, and it has nothing to
do with My.* or upgrading a project:

Public Class Form1
Property Test() As Integer
Get
End Get
Set(ByVal value As Integer)
End Set
End Property

Public Sub set_Test()
End Sub
End Class

 

[Scott M.]

_mytype="empty" in Visual Studio.NET 2005 produced many errors.

camelCase, huh? Well, I used underscores because I present the
names of the test functions (which are synonymous with the class
names) to the user in a test sequence editor. I just instantiate an
object of the type selected by the user.

And, you'd still be able to do that without the underscores. You'd just
have MyName instead of My_Name.

I have heard of style guides for naming conventions, but I did not
realize that these had the same force as speed limit signs.

They don't. I merely pointed out that dropping the underscore in favor of
camelCase/PascalCase has become a "best-practice" not a hard and fast rule
of the road. As has been pointed out, since some of the types that get
automatically generated in .NET use the underscore, the entire issue could
be avoided by not using them.

I thought it was just for ease of following one another's coding
conventions. I have never heard of restrictions on choosing
names for classes, objects, variables, methods, properties,
enumerations, structures, etc., other than stay away from
reserved words.

Again, this isn't a "restriction" per se, it's a best practice. Just as it
is a best practice to name a property with an adjective-like name and a
method with a verb-like name.

I was not aware that name collisions could occur based on appending stuff
to a name.

Unfortunately, you've found out the hard way that this can happen under the
right circumstances.

Lacking any other input, I will build a map of My_Name to
className and rename all of my test function classes to
className convention. Then I can perform a lookup from
My_Name and return className and then use Reflection
on className.

Thanks for your input,
Hamilton Woods

No problem. Good luck.

-Scott