"Allan Ebdrup" <co****@ofir.com> wrote in message
news:Oy**************@TK2MSFTNGP15.phx.gbl...
We have a developer who has defined our vraiable naming conventions, He
has defined that variables should benamed the same as the class they are
an instance of, for example:
Syste.Xml.XmlDocument XmlDocument;
I find this a very bad idea as you might get confused about what
XmlDocument is, a variabel or a class. Do any of you have some good
arguments for or against such a naming convention? Would it be possible to
actually make ambiguous code with such a naming conventions where the
compiler wouldn't know if you mean the class or the variable?
Kind Regards,
Allan Ebdrup
Hi Allan.
Hmm. This is a tough question.
If the class Person is in the Person namespace, and a instance that refers
to a Person through a PersonList with the property Person which is an
indexer that returns an instance of a Person... and so on...
Doesn't that make things a tad confusing? Indeed it does. But it compiles.
This is perhaps why you can't do C# in notepad with grace. You really need a
tool that can show you what is what.
But there are ways to limit this confusion.
1. Don't name namespaces after your classes. Namespaces are there to
categorize and group, not to distinct.
2. Don't name public properties the same as what the getter returns if it
causes confusion.
But with a good tool like Visual Studio I think it's clear what the code
intends.
I don't worry too much a about naming conflicts when I design classes and
public properties.
Happy Organizing
- Michael S