471,592 Members | 1,129 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,592 software developers and data experts.

Naming conventions best practise

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
Nov 17 '05 #1
10 1524
Please refer

http://msdn.microsoft.com/library/de...gpractices.asp

Regards
Prakash Prabhu K
"Allan Ebdrup" wrote:
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

Nov 17 '05 #2
In message <Oy**************@TK2MSFTNGP15.phx.gbl>, Allan Ebdrup
<co****@ofir.com> writes
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.

--
Steve Walker
Nov 17 '05 #3
"Prakash Prabhu K" <Pr************@discussions.microsoft.com> wrote in
message news:0F**********************************@microsof t.com...
Please refer

http://msdn.microsoft.com/library/de...gpractices.asp


That's fine but I can't see where that addresses the issue I write about.
Nov 17 '05 #4

"Allan Ebdrup" wrote...
"Prakash Prabhu K" wrote...

http://msdn.microsoft.com/library/de...gpractices.asp


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
Nov 17 '05 #5
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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 17 '05 #6
"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




Nov 17 '05 #7
Hello,

Michael S wrote:
[...]
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/de...guidelines.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
Nov 17 '05 #8
Allan Ebdrup <co****@ofir.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #9
In message <MP************************@msnews.microsoft.com >, Jon Skeet
<?@pobox.com.invalid> writes
Allan Ebdrup <co****@ofir.com> wrote:
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.


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.

--
Steve Walker
Nov 17 '05 #10
Steve Walker <st***@otolith.demon.co.uk> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Ted | last post: by
4 posts views Thread by Mark Broadbent | last post: by
3 posts views Thread by clintonG | last post: by
5 posts views Thread by Allan Ebdrup | last post: by
48 posts views Thread by Robert Jacobson | last post: by
4 posts views Thread by Sturdy | last post: by
114 posts views Thread by Jonathan Wood | last post: by
35 posts views Thread by Smithers | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.