C# naming conventions (is m_varName used?)

[Zytan]

Is the m_variableName used for data members in C# classes? Since
everything is in a class, it seems that it becomes pointless.

What is the general naming conventions?
What are your personal thoughts?

I've been using m_variableName, but I think I'm going to drop it.

I've also been prefixing classes with clsMyClassName, and forms with
frmMyFormName, abd buttons with btnOK, btnCancel, etc, which all makes
sense. Especially for the classes to avoid name clashes.

Zytan

 

[Dom]

I like using the m_Variable convention, because it allows me to
distinguish between a member variable and a get/set property for it.
For example, a member variable might be "m_Name", and then I have

public String Name
{
get {return m_Name;}
set {m_Name = Value; ...}
}

Plus, old habit die hard.

Dom

 

[Larry Smith]

Is the m_variableName used for data members in C# classes? Since

everything is in a class, it seems that it becomes pointless.

What is the general naming conventions?
What are your personal thoughts?

I've been using m_variableName, but I think I'm going to drop it.

I've also been prefixing classes with clsMyClassName, and forms with
frmMyFormName, abd buttons with btnOK, btnCancel, etc, which all makes
sense. Especially for the classes to avoid name clashes.

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnamingguidelines.asp?frame=true

Note that I flout the conventions on the "m_" issue however. I prefer it
because it clearly indicates you're dealing with a member variable. It
improves legibility IMO but it's a religious issue.

 

[Zytan]

I like using the m_Variable convention, because it allows me to

distinguish between a member variable and a get/set property for it.
For example, a member variable might be "m_Name", and then I have

public String Name
{
get {return m_Name;}
set {m_Name = Value; ...}

}

Plus, old habit die hard.

Yup, but you raise a good point. thanks

Zytan

 

[> Adrian]

Look here, the wheel has been discovered:

http://www.tiobe.com/standards/gemrcsharpcs.pdf

Adrian.

 

[Zytan]

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnamingguid...

Note that I flout the conventions on the "m_" issue however. I prefer it
because it clearly indicates you're dealing with a member variable. It
improves legibility IMO but it's a religious issue.

Thanks for the link. I like "m_" as well because it means a member
var. But it seems that almost everything is a member var, so I wonder
if that changes the need for it.

But, yeah, in a function with mixed parameters and member vars, it's
nice to know which is which, "m_" is here to stay.

Zytan

 

[Zytan]

I've also been prefixing classes with clsMyClassName, and forms with

frmMyFormName, abd buttons with btnOK, btnCancel, etc, which all makes
sense. Especially for the classes to avoid name clashes.

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconClassNamingGuidelines.asp
States to not use any prefix at all for class names, but, that means
name clashes are so much more likely.

What do you guys do?

Zytan

 

[Zytan]

Look here, the wheel has been discovered:

http://www.tiobe.com/standards/gemrcsharpcs.pdf

The file is way too verbose. I think I'll stick with:
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconNamingGuidelines.asp

After all, I'm just trying to find a starting place, such as using
"m_" or not for member vars, and using "cls" prefix for classes (which
I note VB developers using, maybe that was the thing to do
before .NET?)

Zytan

 

[james]

I have been using

http://www.idesign.net/idesign/download/IDesign CSharp Coding Standard.zip

Its short and to the point. And they say use m_VariableName.

-James

 

[Zytan]

http://www.idesign.net/idesign/download/IDesign CSharp Coding S...

Its short and to the point. And they say use m_VariableName.

-James

Thanks James, great document!

Zytan

 

[Dom]

Using "cls" for classes (and "nms" for namespaces) saves alot on
clashes, but I don't care for the look of it in public objects. For
example,
StatusReport s = new StatusReport ();

looks better than
clsStatusReport s = new clsStatusReport ();

Dom

 

[Zytan]

Using "cls" for classes (and "nms" for namespaces) saves alot on

clashes, but I don't care for the look of it in public objects. For
example,
StatusReport s = new StatusReport ();

looks better than
clsStatusReport s = new clsStatusReport ();

I totally agree. I personally hate the way "cls" looks.

I guess the only solution is to make class names more complicated to
avoid clashes.

Zytan

 

[Jon Skeet [C# MVP]]

Is the m_variableName used for data members in C# classes? Since
everything is in a class, it seems that it becomes pointless.

What is the general naming conventions?
What are your personal thoughts?

I've been using m_variableName, but I think I'm going to drop it.

Well, at work I use m_variableName for instance variables,
g_variableName for static variables, and no prefix for locals. For
personal projects, I don't use a prefix at all.

Personally, for private variables, I think it's fine to use whatever
convention you like, pretty much - just be consistent, and don't let it
spill out into the non-private API.

I've also been prefixing classes with clsMyClassName, and forms with
frmMyFormName, abd buttons with btnOK, btnCancel, etc, which all makes
sense. Especially for the classes to avoid name clashes.

I'm not keen on that kind of thing myself. Give the name whatever's
meaningful - it often makes sense to call a UI variable something which
includes the type, but beyond that it's rarely useful. For instance,
"sName" is no more useful than "name", but harder to mentally "read
aloud" IMO.

 

[Jon Skeet [C# MVP]]

But, yeah, in a function with mixed parameters and member vars, it's
nice to know which is which, "m_" is here to stay.

I rarely find it's an issue, to be honest - it should usually be clear
from the usage, and methods shouldn't be so long that you can't see the
declarations of all the local variables anyway. On the other hand,
having g_ and m_ does make it obvious when you're accessing something
static in a situation where you shouldn't be.

 

[Bruce Wood]

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconClassNamin...
States to not use any prefix at all for class names, but, that means
name clashes are so much more likely.

How are name clashes more likely? There is nothing stopping you from
having a property / method name the same as a class name, in fact I
prefer it:

public Warehouse Warehouse
{
get { return this._warehouse; }
set { this._warehouse = value; }
}

(And yes, I use the _ convention rather than m_ ... I like the fact
that in the debugger and in Intellisense it puts the fields first in
the locals window / pick list. One more convention for you to think
about.

 

[Jon Skeet [C# MVP]]

I totally agree. I personally hate the way "cls" looks.

I guess the only solution is to make class names more complicated to
avoid clashes.

Don't think of it as making them more complicated - make them
descriptive instead. It's not the end of the world to have multiple
classes with the same name in different namespaces, although obviously
it's best to avoid it where possible.

I can't say I run into it very frequently.

What I *would* strongly recommend is changing the names the designer
gives you: "Form1" isn't descriptive at all, nor is "label1", and
"button1_Clicked" or whatever it suggests is neither descriptive nor
follows the .NET naming conventions.

Then again, as many in the group know, I dislike designers which build
code anyway. (I'm much more of a fan of the XAML style of working.)

 

[PhilipDaniels]

On Feb 28, 9:38 am, "Zytan" <[email protected]> wrote:

(And yes, I use the _ convention rather than m_ ... I like the fact
that in the debugger and in Intellisense it puts the fields first in
the locals window / pick list. One more convention for you to think
about.

It always bugged me (pun intended) that the debugger showed both the
private field and the property that exposed it, thus duplicating
information and wasting space. So now I use this attribute liberally
on fields which can be read via property-gets:

[DebuggerBrowsable(DebuggerBrowsableState.Never)]

 

[james]

I completely agree Dom. Too much of that stuff will make C# look like
C++, and I never again want to see unlegible monstrosities like
KBDLLHOOKSTRUCT and __dllimport void *libq_calloc(...

-James

 

[Zytan]

I rarely find it's an issue, to be honest - it should usually be clear

from the usage,...

Yes, but still, seeing "m_" allows a much more quick determination
that to analyze the usage. Any variable can be determined by its
usage, even if the names are bad. Good naming conventions exist to
nullify that time wasted.

...and methods shouldn't be so long that you can't see the
declarations of all the local variables anyway.

Yes. Something I need work on.

On the other hand,
having g_ and m_ does make it obvious when you're accessing something
static in a situation where you shouldn't be.

"g_" = ? (Not global, since C# disallows that.)

Zytan

 

[Zytan]

I totally agree. I personally hate the way "cls" looks.

Don't think of it as making them more complicated - make them
descriptive instead. It's not the end of the world to have multiple
classes with the same name in different namespaces, although obviously
it's best to avoid it where possible.

Yes, more descriptive is what I meant. But, when I could shorten it,
and still be descriptive, then by lengthening it is making it more
complex. But, in doing so, you have the option to improve
description, yes.

I can't say I run into it very frequently.

What I *would* strongly recommend is changing the names the designer
gives you: "Form1" isn't descriptive at all, nor is "label1", and
"button1_Clicked" or whatever it suggests is neither descriptive nor
follows the .NET naming conventions.

I do that immediately. I've been using btn, frm, txt, etc. prefixes
for everything. But, I leave the function names it creates alone, as
I thought they were standard: btnCancel_Clicked (what's wrong with
that), and even the event handler names.

Then again, as many in the group know, I dislike designers which build
code anyway. (I'm much more of a fan of the XAML style of working.)

I always did, too, greatly, until C#.

XAML = ? (I'll look it up.)

Zytan.