Naming Conventions dot net/csharp

[Mark Broadbent]

stupid question time again to most of you experts but this is something that
continually bothers me.
I am trying to get into the habit of naming variables and controls in an
assembly as per convensions. The thing is that Ive never really get the full
reference to check against.
Ive seen a couple of articles, but there always seems to be a bit missing. I
also always seem to run into conflicting convensions both in code samples
themselves or between different articles.
For instance, in one article it stated that class private and protected
variables should be named underscore+camelcase e.g. _likeThis
But I never seem to come across this in peoples' code samples (whether MS
employee or not).
Another ambigious thing I have noticed (even steming back to VB conventions)
is that when naming controls, I dont seem to find a standard for radiobutton
(i.e. something like rdoMyButton).

So in brief what I am looking for is.....
Naming standards for everything throughout an Assembly. Additionally full
standards as far as is possible for controls. Also could someone clarify
whether class Naming convention is applied to the design time element, the
instance or both. Finally could someone give me conventions for the solution
explorer elements such as the code files *.cs

Thanks!


--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Jon Skeet [C# MVP]]

stupid question time again to most of you experts but this is something that
continually bothers me.
I am trying to get into the habit of naming variables and controls in an
assembly as per convensions. The thing is that Ive never really get the full
reference to check against.

The main one is

http://tinyurl.com/2cun

Ive seen a couple of articles, but there always seems to be a bit missing. I
also always seem to run into conflicting convensions both in code samples
themselves or between different articles.
For instance, in one article it stated that class private and protected
variables should be named underscore+camelcase e.g. _likeThis
But I never seem to come across this in peoples' code samples (whether MS
employee or not).

Protected variables need to follow a public naming convention, but for
private variables and methods you can use your own convention.
Personally I don't use any prefixes or anything, but lots of others do.

Another ambigious thing I have noticed (even steming back to VB conventions)
is that when naming controls, I dont seem to find a standard for radiobutton
(i.e. something like rdoMyButton).

So in brief what I am looking for is.....
Naming standards for everything throughout an Assembly. Additionally full
standards as far as is possible for controls.

Well, MS only specify *public* naming conventions, but you'll find
plenty of differing opinions about other stuff. It's important that you
or your company standardises on a naming convention for private stuff,
but it doesn't matter too much what that convention is.

Also could someone clarify
whether class Naming convention is applied to the design time element, the
instance or both.

Not sure what you mean here - could you clarify?

Finally could someone give me conventions for the solution
explorer elements such as the code files *.cs

That's really up to you/your company - it won't make much odds to the
outside world. Actually, that's not quite true - if you're writing a
library which implements a certain namespace, it's conventional to name
the assembly by the namespace, eg Foo.Bar.dll for namespace Foo.Bar.

 

[Mark Broadbent]

yeah thanks. Id seen that one before but feel it is missing an awful lot
(such as control, private members etc). The other good link Id found was
http://www.irritatedvowel.com/Programming/Standards.aspx
but that doesnt give a prefix for each control (although it states name them
in Hungarian style).
I'd hoped that for something I consider important that a "bible" would exist
somewhere?

personally I would prefer the Editor to apply a formatting template to the
variable /class/ interface/ control etc.
e.g I create a texbox it creates name txtTextbox1 where txt is implied by
the control and cant be removed -and the camel casing cannot be changed
although the text "Textbox1" can. Or a private class variable is created so
_ is implied and is prefix to (and cant be changed) the variable text (which
is also enforced to be Pascal case.
I think this would speed development up hugely. For companies that enforce
there own standards, templates could be modified....The option to turn off
this behaviour could also exist.
Whether or not this is in Whidbey I will live in hope

--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Mark Broadbent]

just seen the rest of your reply (didnt scroll down!). Yes that would
explain why the class level vars and controls conventions differ so much
(cos there aint a set standard). just constantly find myself changing my
mind about how and what I call something (which is probably the worst thing
I can do).

You wanted me to clarify what I was going on about when I mention would I
apply the naming convention to a class, instance or both. What I meant is
that say for example I am using PascalCase for my class FooBar does it
follow that I should also use Pascal casing for any instances of that class

class FooBar
{...}

class App
{
private FooBar AnotherFoo=new FooBar();
public FooBar PubFoo=new FooBar();
.....
}

because in this example there is a public object and a private one.
--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Jon Skeet [C# MVP]]

just seen the rest of your reply (didnt scroll down!). Yes that would
explain why the class level vars and controls conventions differ so much
(cos there aint a set standard). just constantly find myself changing my
mind about how and what I call something (which is probably the worst thing
I can do).

You wanted me to clarify what I was going on about when I mention would I
apply the naming convention to a class, instance or both. What I meant is
that say for example I am using PascalCase for my class FooBar does it
follow that I should also use Pascal casing for any instances of that class

class FooBar
{...}

class App
{
private FooBar AnotherFoo=new FooBar();
public FooBar PubFoo=new FooBar();
....
}

because in this example there is a public object and a private one.
--

No. There's no such thing as a public object and a private one - there
are only private and public *members*.

I would suggest only having public fields which are readonly, and
treating them like other constants, i.e. using Pascal casing. I can't
immediately think of any public members which wouldn't use Pascal
casing, in fact.