By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,677 Members | 1,303 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,677 IT Pros & Developers. It's quick & easy.

C# naming conventions (is m_varName used?)

P: n/a
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

Feb 28 '07 #1
Share this Question
Share on Google+
47 Replies


P: n/a
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
On Feb 28, 11:47 am, "Zytan" <zytanlith...@yahoo.comwrote:
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

Feb 28 '07 #2

P: n/a
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...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.
Feb 28 '07 #3

P: n/a
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

Feb 28 '07 #4

P: n/a
Look here, the wheel has been discovered:

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

Adrian.
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@a75g2000cwd.googlegro ups.com...
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

Feb 28 '07 #5

P: n/a
http://msdn.microsoft.com/library/en...pconnamingguid...
>
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

Feb 28 '07 #6

P: n/a
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...Guidelines.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

Feb 28 '07 #7

P: n/a
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...Guidelines.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

Feb 28 '07 #8

P: n/a
I have been using

http://www.idesign.net/idesign/downl...20Standard.zip

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

-James

Feb 28 '07 #9

P: n/a
http://www.idesign.net/idesign/downl...p%20Coding%20S...
>
Its short and to the point. And they say use m_VariableName.

-James
Thanks James, great document!

Zytan

Feb 28 '07 #10

P: n/a
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
On Feb 28, 12:38 pm, "Zytan" <zytanlith...@yahoo.comwrote:
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...pconClassNamin...
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

Feb 28 '07 #11

P: n/a
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

Feb 28 '07 #12

P: n/a
Zytan <zy**********@yahoo.comwrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #13

P: n/a
On Feb 28, 9:38 am, "Zytan" <zytanlith...@yahoo.comwrote:
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...pconClassNamin...
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. :-)

Feb 28 '07 #14

P: n/a
Zytan <zy**********@yahoo.comwrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #15

P: n/a
Zytan <zy**********@yahoo.comwrote:
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.
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.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #16

P: n/a
On 28 Feb 2007 10:39:10 -0800, "Bruce Wood" <br*******@canada.com>
wrote:
>On Feb 28, 9:38 am, "Zytan" <zytanlith...@yahoo.comwrote:
>(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)]

--
Philip Daniels
Feb 28 '07 #17

P: n/a
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

Feb 28 '07 #18

P: n/a
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

Feb 28 '07 #19

P: n/a
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.
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.

Feb 28 '07 #20

P: n/a
http://msdn.microsoft.com/library/en...pconClassNamin...
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?
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

Feb 28 '07 #21

P: n/a
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

Feb 28 '07 #22

P: n/a
Zytan <zy**********@yahoo.comwrote:
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.
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.
...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.)
Statics.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #23

P: n/a
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).
Feb 28 '07 #24

P: n/a
Zytan <zy**********@yahoo.comwrote:
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.
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.
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.)
Enjoy :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #25

P: n/a
Zytan <zy**********@yahoo.comwrote:
>http://msdn.microsoft.com/library/en...pconClassNamin...
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?

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.
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.
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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #26

P: n/a
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.
True, good thoughts.

Zytan

Feb 28 '07 #27

P: n/a
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.
Ok. So, you must use the namespace to avoid it. I see. I'll
consider.
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.

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

Feb 28 '07 #28

P: n/a
Jon Skeet [C# MVP] wrote:
>"g_" = ? (Not global, since C# disallows that.)

Statics.
In what language does "statics" begin with "g"? ;)

--
Göran Andersson
_____
http://www.guffa.com
Feb 28 '07 #29

P: n/a
"g_" = ? (Not global, since C# disallows that.)
>
Statics.

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

Feb 28 '07 #30

P: n/a
Zytan wrote:
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? ;)

--
Göran Andersson
_____
http://www.guffa.com
Feb 28 '07 #31

P: n/a
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? ;)
_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

Mar 1 '07 #32

P: n/a
On Feb 28, 8:47 am, "Zytan" <zytanlith...@yahoo.comwrote:
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

Mar 1 '07 #33

P: n/a
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

Mar 1 '07 #34

P: n/a
On 28 Feb 2007 09:38:04 -0800, "Zytan" <zy**********@yahoo.comwrote:
>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...Guidelines.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
Mar 1 '07 #35

P: n/a
[snip]
All of the above inside a class...

Good luck with your project,
Ok, thanks, Otis!

Zytan

Mar 1 '07 #36

P: n/a
Zytan <zy**********@yahoo.comwrote:
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?
Wouldn't like to say. I suspect others use s_ for static. Doesn't
matter much, really.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #37

P: n/a
Göran Andersson <gu***@guffa.comwrote:
Jon Skeet [C# MVP] wrote:
"g_" = ? (Not global, since C# disallows that.)
Statics.
In what language does "statics" begin with "g"? ;)
I suspect it grew out of statics being close (in some ways) to globals.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #38

P: n/a
On 28 Feb 2007 10:12:10 -0800, "Zytan" <zy**********@yahoo.comwrote:
>http://www.idesign.net/idesign/downl...p%20Coding%20S...

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

-James

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.
--
http://www.kynosarges.de
Mar 1 '07 #39

P: n/a
On 28 Feb 2007 16:48:53 -0800, "Quoc Linh" <le********@yahoo.com>
wrote:
>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...
--
http://www.kynosarges.de
Mar 1 '07 #40

P: n/a
Am 28 Feb 2007 08:47:32 -0800 schrieb 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
Hello Zytan,
not everything is in a class. Local variables, e.g., are not.
OTOH, the members of struct Point { int x, int y } probably should not
receive a prefix either.

To find a good convention, ask yourself the following questions:
- What do you want to express in addition to the name?
- Do you want to use case as a distinguisher?
- Do you want to prefix or postfix?
- What are the abbreviation rules?
- Do you want to use underscores?

In addition, think of the following:
- Intellisense issues
- human readability

My 2 cents...
Paule



Mar 1 '07 #41

P: n/a
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...
No he won't, because he is not that concerned. :) I just wanted to
know some general ideas, which this thread has shown me. So, thanks
everyone. FxCop is beyond anything I need at this time.

Zytan

Mar 1 '07 #42

P: n/a
On Feb 28, 5:08 pm, "Zytan" <zytanlith...@yahoo.comwrote:
>
I think it started in C++, meaning "member".
Ah, I do recall now, although I see it more common in VB than in C++
(the m_). The C++ world I know use _ for class private members, and
g_ for globals. But variations happen in the world as it should
be ;-)

Quoc Linh

Mar 1 '07 #43

P: n/a
Most developers invent their own style. But if you
are working in a team, you need acceptable standards,
not only for nomenclature.

Don't prefix (or suffix) underscores ( _) terrible habit that.
Be consistent.

Adrian.

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@k78g2000cwa.googlegr oups.com...
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...Guidelines.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

Mar 1 '07 #44

P: n/a
On Thu, 1 Mar 2007 19:35:32 +0100, "Adrian <" <x@xx.xxwrote:
>Don't prefix (or suffix) underscores ( _) terrible habit that.
Do prefix underscores for private class variables. Wonderful habit,
and makes it easy to find private identifiers with IntelliSense!
--
http://www.kynosarges.de
Mar 1 '07 #45

P: n/a
On Mar 1, 1:52 pm, Chris Nahr <dioge...@kynosarges.dewrote:
On Thu, 1 Mar 2007 19:35:32 +0100, "Adrian <" <x...@xx.xxwrote:
Don't prefix (or suffix) underscores ( _) terrible habit that.

Do prefix underscores for private class variables. Wonderful habit,
and makes it easy to find private identifiers with IntelliSense!
--http://www.kynosarges.de
I concur Chris.

Adrian, how do you named your private class variables? For me, it's a
must to distinct them otherwise my developer life would be miserable.

Quoc Linh

Mar 1 '07 #46

P: n/a
I don't do it with horrible prefixed underscores.
Adrian.

"Quoc Linh" <le********@yahoo.comwrote in message
news:11********************@z35g2000cwz.googlegrou ps.com...
On Mar 1, 1:52 pm, Chris Nahr <dioge...@kynosarges.dewrote:
On Thu, 1 Mar 2007 19:35:32 +0100, "Adrian <" <x...@xx.xxwrote:
>Don't prefix (or suffix) underscores ( _) terrible habit that.
Do prefix underscores for private class variables. Wonderful habit,
and makes it easy to find private identifiers with IntelliSense!
--http://www.kynosarges.de

I concur Chris.

Adrian, how do you named your private class variables? For me, it's a
must to distinct them otherwise my developer life would be miserable.

Quoc Linh

Mar 1 '07 #47

P: n/a
On Mar 1, 2:55 pm, "Quoc Linh" <lequocl...@yahoo.comwrote:
On Mar 1, 1:52 pm, Chris Nahr <dioge...@kynosarges.dewrote:
On Thu, 1 Mar 2007 19:35:32 +0100, "Adrian <" <x...@xx.xxwrote:
>Don't prefix (or suffix) underscores ( _) terrible habit that.
Do prefix underscores for private class variables. Wonderful habit,
and makes it easy to find private identifiers with IntelliSense!
--http://www.kynosarges.de

I concur Chris.

Adrian, how do you named your private class variables? For me, it's a
must to distinct them otherwise my developer life would be miserable.

Quoc Linh
private int myVariable;

public void f() {
int localInt = 0;
this.myVariable += myVariable;
}

I've had standards that insisted that member variables be prefixed
with m_, method args with a_, and local variables with l_. Every new
acquisition brought code done with a different standard. I dispense
with prefixes whenever I can.

Mar 2 '07 #48

This discussion thread is closed

Replies have been disabled for this discussion.