C# naming conventions (is m_varName used?)

[Zytan]

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

How are name clashes more likely?

Like this: I want a class named Socket. It clashes with .NET Socket
class. clsSocket does not. So, in picking single word class names,
there's more likely to be a clash with Word then clsWord. In fact,
clsWord will never clash, so 'clashes are so much more likely' should
really be 'clashes are now possible'.

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; }
}

Didn't know that. Thanks. I can't say I like it, though. Isn't it
best, as Jon Skeet touch upon, to have everything named differently,
including the above example? Looks like a constructor at first glance
to me.

(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.

Good idea, and thanks! I won't use it, because I like the "m" telling
me "I'm a *m*ember", but good idea.

Zytan

 

[Zytan]

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.

Ah, g_ means static. I never thought to use a different convention
for that. Is that standard?

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.

Quite true.

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.

Yes, I don't use clsClass to remind me that Class is a class, it's
just to avoid clashes, and I seen VB people using cls, so I did, as
well. I will drop this, as it's not standard.

Zytan

 

[Jon Skeet [C# MVP]]

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.

But at the same time, they can be distractions. You can't read a line
of code containing prefixes aloud without it sounding silly, unless you
mentally remove the prefixes.

In other words, it's a balancing act.

Yes. Something I need work on.


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

Statics.

 

[Larry Smith]

I do that immediately. I've been using btn, frm, txt, etc. prefixes

for everything.

There's no fixed rule of course but most experieced developers would probaly
balk at it. "m_" is one thing because it's been around so long (and is
highly recognized) but most others are really just "warts" IMO (to coin an
expression frequently used to describe Hungarian notation in the C++ world).

 

[Jon Skeet [C# MVP]]

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.

What's wrong with it is that it violates .NET naming conventions, which
are in Pascal case, and which don't use underscores. Furthermore, it's
not a verb phrase. Personally I would prefer HandleCancelButtonClicked
if I didn't have anything more descriptive to put there - but often
what the method *does* isn't directly related to the fact that it
happens to be hooked up to an event. So name the method after what it
actually does, and then the event hooking up code makes it clear what
happens when the cancel button is clicked.

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

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

Enjoy

 

[Jon Skeet [C# MVP]]

Like this: I want a class named Socket. It clashes with .NET Socket
class. clsSocket does not. So, in picking single word class names,
there's more likely to be a clash with Word then clsWord. In fact,
clsWord will never clash, so 'clashes are so much more likely' should
really be 'clashes are now possible'.

If it's a Socket in some non-network fashion, I'd certainly live with
the clash - let the namespace give the context. If it's similar to the
..NET Socket class, I'd expand the name to make it clear what the
difference was.

Didn't know that. Thanks. I can't say I like it, though. Isn't it
best, as Jon Skeet touch upon, to have everything named differently,
including the above example? Looks like a constructor at first glance
to me.

Not if you know you're looking in a class which isn't called Warehouse.
(Actually, I can't see that it looks anything like a constructor,
personally

 

[Zytan]

I do that immediately. I've been using btn, frm, txt, etc. prefixes

What's wrong with it is that it violates .NET naming conventions, which
are in Pascal case, and which don't use underscores. Furthermore, it's
not a verb phrase. Personally I would prefer HandleCancelButtonClicked
if I didn't have anything more descriptive to put there - but often
what the method *does* isn't directly related to the fact that it
happens to be hooked up to an event. So name the method after what it
actually does, and then the event hooking up code makes it clear what
happens when the cancel button is clicked.

True, good thoughts.

Zytan

 

[Zytan]

Like this: I want a class named Socket. It clashes with .NET Socket

If it's a Socket in some non-network fashion, I'd certainly live with
the clash - let the namespace give the context. If it's similar to the
.NET Socket class, I'd expand the name to make it clear what the
difference was.

Ok. So, you must use the namespace to avoid it. I see. I'll
consider.

Not if you know you're looking in a class which isn't called Warehouse.
(Actually, I can't see that it looks anything like a constructor,
personally

That's true.

Zytan

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Statics.

In what language does "statics" begin with "g"?

 

[Zytan]

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

In what language does "statics" begin with "g"?

Good point. Why not use "s_"? I could see "g_" for global (in a
language that supports it).

Zytan

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I want a class named Socket. It clashes with .NET Socket
class. clsSocket does not.

For that purpose you could use anything that is non-standard, as that
won't clash with classes who's name follows the standard.

What about zytanSocket or _oOo_Socket?

 

[Zytan]

I want a class named Socket. It clashes with .NET Socket

For that purpose you could use anything that is non-standard, as that
won't clash with classes who's name follows the standard.

What about zytanSocket or _oOo_Socket?

_oOo_Socket it is!



No, I just appended another word to it, and removed 'cls'. I think
that's best. Did the same for 'frm' prefix for 'Form'.

Zytan

 

[Quoc Linh]

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

To waste less time on debating on convention and develop coding
standard document, simply use FxCop. Make a rule for all your
developers: Do not consider the code is done and compliant unless
everything is compliant with FxCop, and there should not be any
warning errors in your compile results either. This will ensure an
automatic way of a semi-complete code review on all your developers'
code, keep code clean even if it is developed by temporary contractors
that will be gone in 6 months, and get rid of all warning errors will
eliminate some hidden nasty bugs and keep developer having a good
habit: alert.

I took over too many projects that "boggles the mind" of what have
happened, and I think FxCop is the most efficient way to go. Of
course, if you plan to suggest this, you might also run into certain
know-it-all Development Director that think FxCop is too fussy and
will not allowed FxCop on his turf ... ouch! Gentle warning bells
should be ringing in taking that contract

Regard your question, personally, I use the underscore _ instead of
the awkward m_ for private class declarations. m_ is from the VB erra
of having module level which is no longer true in .Net C# or .Net VB

HTH,
Quoc Linh

 

[Zytan]

To waste less time on debating on convention and develop coding

standard document, simply use FxCop.
[snip]

I'll take a look at FxCop.

Regard your question, personally, I use the underscore _ instead of
the awkward m_ for private class declarations. m_ is from the VB erra
of having module level which is no longer true in .Net C# or .Net VB

I think it started in C++, meaning "member".

Thanks for your input.

Zytan

 

[Otis Mukinfus]

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

private _thisVar

private void _someMethod()
{
string myVar = string.Empty;
}

public void SomeMethod()
{
string myVar = null;
}

All of the above inside a class...


Good luck with your project,

Otis Mukinfus

http://www.otismukinfus.com
http://www.arltex.com
http://www.tomchilders.com
http://www.n5ge.com

 

[Zytan]

[snip]

All of the above inside a class...

Good luck with your project,

Ok, thanks, Otis!

Zytan

 

[Jon Skeet [C# MVP]]

Ah, g_ means static. I never thought to use a different convention
for that. Is that standard?

Wouldn't like to say. I suspect others use s_ for static. Doesn't
matter much, really.

 

[Jon Skeet [C# MVP]]

In what language does "statics" begin with "g"?

I suspect it grew out of statics being close (in some ways) to globals.

 

[Chris Nahr]

Thanks James, great document!

Zytan

Please note that these are some company's internal guidelines, not the
ones recommended by Microsoft or generally accepted by anyone else,
except insofar as they overlap with the Microsoft guidelines.

If you want to know about .NET coding conventions, not just naming,
get "Framework Design Guidelines" by Cwalina/Abrams. This excellent
book also describes the design ideas behind the Framework libraries.

 

[Chris Nahr]

I took over too many projects that "boggles the mind" of what have
happened, and I think FxCop is the most efficient way to go. Of
course, if you plan to suggest this, you might also run into certain
know-it-all Development Director that think FxCop is too fussy and
will not allowed FxCop on his turf ... ouch! Gentle warning bells
should be ringing in taking that contract

Not at all. FxCop is unreliable and indeed way too fussy, usually
over random irrelevant issues. Most of its warnings have little to do
with code quality, and much with the personal preferences of the
tool's authors. But Zytan will soon discover that for himself...