Naming conventions best practise

[Allan Ebdrup]

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

 

[Guest]

Please refer

http://msdn.microsoft.com/library/d...vxconcodingtechniquesprogrammingpractices.asp

Regards
Prakash Prabhu K

 

[Steve Walker]

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?

It causes problems with intellisense for static methods. If he wants to
use it, he should camel-case the variable name. I wouldn't adopt it as a
rigid standard. Sometimes the class name (appropriately cased) is also a
good candidate for a variable name. Sometimes it isn't.

 

[Allan Ebdrup]

Please refer

http://msdn.microsoft.com/library/d...vxconcodingtechniquesprogrammingpractices.asp

That's fine but I can't see where that addresses the issue I write about.

 

[Bjorn Abelli]

...

That's fine but I can't see where that addresses the issue
I write about.

It actually does, in many places.

E.g. the naming of an identifier should tell "what" rather than "how." By
avoiding names that expose the underlying implementation, which can change,
you preserve a layer of abstraction that simplifies the complexity.

The coding standard in MSDN also suggest using camel casing rather than
pascal casing for variable names.

// Bjorn A

 

[Mattias Sjögren]

Do any of you have some good arguments for or
against such a naming convention?

Well it only works for a single instance of the same type in a scope.
What would he do if he ever needed to use two XmlDocuments?



Mattias

 

[Michael S]

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

 

[Bernhard Huemer]

Hello,

[...]
2. Don't name public properties the same as what the getter returns if it
causes confusion.
[...]

In general I'm in complete agreement, but this guideline can also cause
problems. Consider following naming guideline:

"Property Naming Guidelines":
http://msdn.microsoft.com/library/d...genref/html/cpconpropertynamingguidelines.asp

Of course this problem gets a thing of the past by using the global
keyword, but personally I don't like this keyword very much ..

bye

 

[Jon Skeet [C# MVP]]

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?

It's a terrible convention. The type of a variable can easily be found
out in other ways. What's far more important is the *purpose* of the
variable - what its *meaning* is. Can you imagine reading a program
where every String was called "String" (or "String1", "String2" etc)?

It also forces you to use full type names everywhere to disambiguate
between variable names and type names.

I suggest you protest in the strongest possible terms.

 

[Steve Walker]

It's a terrible convention. The type of a variable can easily be found
out in other ways. What's far more important is the *purpose* of the
variable - what its *meaning* is. Can you imagine reading a program
where every String was called "String" (or "String1", "String2" etc)?

It also forces you to use full type names everywhere to disambiguate
between variable names and type names.

I suggest you protest in the strongest possible terms.

Agreed. It's a terrible convention, but I wouldn't go so far as saying
that the converse is true. I've got classes which look like:

class House
{
private Address address;
public Address Address{get{return this.address;}}
}

In cases where the most sensible address name is also the most sensible
member and property name, I don't believe in making up synonyms purely
for the sake of having different names.

 

[Jon Skeet [C# MVP]]

Agreed. It's a terrible convention, but I wouldn't go so far as saying
that the converse is true. I've got classes which look like:

class House
{
private Address address;
public Address Address{get{return this.address;}}
}

In cases where the most sensible address name is also the most sensible
member and property name, I don't believe in making up synonyms purely
for the sake of having different names.

Oh absolutely - there are definitely times when the semantic meaning is
best indicated using the type name, and I don't shy away from thing
like the above.