Coding Conventions for C#

[Andrea Williams]

Responding to this link in an old thread:
http://msdn.microsoft.com/library/de...us/cpgenref/ht
ml/cpconnetframeworkdesignguidelines.asp

According to that naming convention, a parameter should be be named like
this "typeName" (ei stringFirstName). The types that they list add to the
variable name and the amount of typing to do by quite a lot when compounded
by the amount of code that goesinto creating an app. Is there anyone still
using the hungarian convention or a variation of it?

Even though the hungarian convention is supposedly no longer considered good
in the Naming Conventions for Microsoft, I'm considering using it just to
cut down and the amount of typing. Any programmer is going to know what it
means and it will cut down on the amount of code.

Maybe there's a good reason for typing out the whole data type word,
anyone??

I would also prefer to perfix private members with something. VB used "m_"
and it looks like c++ did as well, although it may be a little messy... I
think I like just the underscore only, "_".

Also, I believer the basic reason that the hungarian notation is out is due
to the fact that VS.NET is strongly typed. But that only helps you IF you
are using VS.NET. If you're using some other program, say like Notepad, you
wouldn't have the benefit of iintellisense and I would think that the
hungarian notation would still be valuable.

Any other thoughts?

I have the task of setting up our company naming and coding conventions and
I would like extra input before I settle on one specific set of guidlines.

Thanks in advance,

Andrea Williams

[Tony Nassar]

I like an abbreviated Hungarian notation for .NET controls; it makes using
the code completion much easier. I used to have C++ that explicitly
referenced "this," but now I do it all the time in C#, for similar reasons.
My company's standard prefix for member variables is "m_"; I *don't* like
that because it requires me to type an extra two characters, incl. that
inconvenient '_', to get code completion. However,
using '_' as a prefix is short-sighted; it's NOT CLS-compliant, and in the
world of C/C++, it's often considered bad style (because of collisions with
legacy globals).

On the other hand, strings are so ubiquitous that prefixing every string
variable with "string" seems silly, to say nothing of "num", "countOf", etc.

[mikeb]

Andrea Williams wrote:

Responding to this link in an old thread:
http://msdn.microsoft.com/library/de...us/cpgenref/ht
ml/cpconnetframeworkdesignguidelines.asp

According to that naming convention, a parameter should be be named like
this "typeName" (ei stringFirstName). The types that they list add to the
variable name and the amount of typing to do by quite a lot when compounded
by the amount of code that goesinto creating an app. Is there anyone still
using the hungarian convention or a variation of it?
I think you're getting a bit confused on what they're advocating - they
don't suggest prefixing parameter names with the type of the parameter.
Note that in the example they give, the typeName parameter is a string
type, but they didn't call it stringName.

The guidelines explicitly say:

================================================
Use names that describe a parameter's meaning rather than names that
describe a parameter's type. Development tools should provide meaningful
information about a parameter's type. Therefore, a parameter's name can
be put to better use by describing meaning. Use type-based parameter
names sparingly and only where it is appropriate.
================================================

Even though the hungarian convention is supposedly no longer considered good
in the Naming Conventions for Microsoft, I'm considering using it just to
cut down and the amount of typing. Any programmer is going to know what it
means and it will cut down on the amount of code.

Maybe there's a good reason for typing out the whole data type word,
anyone??

I would also prefer to perfix private members with something. VB used "m_"
and it looks like c++ did as well, although it may be a little messy... I
think I like just the underscore only, "_".

Also, I believer the basic reason that the hungarian notation is out is due
to the fact that VS.NET is strongly typed. But that only helps you IF you
are using VS.NET. If you're using some other program, say like Notepad, you
wouldn't have the benefit of iintellisense and I would think that the
hungarian notation would still be valuable.

Any other thoughts?

I have the task of setting up our company naming and coding conventions and
I would like extra input before I settle on one specific set of guidlines.

Thanks in advance,

Andrea Williams

--
mikeb

[Andrea Williams]

So if the TYPE in typeName doesn't indicate the data type, what does it
indicate. The example showed the following:

[Visual Basic]
Sub Write(doubleValue As Double);
Sub Write(singleValue As Single);
Sub Write(longValue As Long);
Sub Write(integerValue As Integer);
Sub Write(shortValue As Short);
[C#]
void Write(double doubleValue);
void Write(float floatValue);
void Write(long longValue);
void Write(int intValue);
void Write(short shortValue);

My resource:
http://msdn.microsoft.com/library/de...econfusion.asp

What am I misinterpreting here??

Andrea

I think you're getting a bit confused on what they're advocating - they
don't suggest prefixing parameter names with the type of the parameter.
Note that in the example they give, the typeName parameter is a string
type, but they didn't call it stringName.

The guidelines explicitly say:

================================================
Use names that describe a parameter's meaning rather than names that
describe a parameter's type. Development tools should provide meaningful
information about a parameter's type. Therefore, a parameter's name can
be put to better use by describing meaning. Use type-based parameter
names sparingly and only where it is appropriate.
================================================

--
mikeb

[Andrea Williams]

So I'm curious, do they have you use three character prefixes or one
character on most and three when needed?

Example:
string strName;
string sName;

So I should be safe if I just add the 'm' for private members, right? No
legacy issues with that I hope?

Andrea
"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

I like an abbreviated Hungarian notation for .NET controls; it makes using
the code completion much easier. I used to have C++ that explicitly
referenced "this," but now I do it all the time in C#, for similar reasons. My company's standard prefix for member variables is "m_"; I *don't* like
that because it requires me to type an extra two characters, incl. that
inconvenient '_', to get code completion. However,
using '_' as a prefix is short-sighted; it's NOT CLS-compliant, and in the
world of C/C++, it's often considered bad style (because of collisions with legacy globals).

On the other hand, strings are so ubiquitous that prefixing every string
variable with "string" seems silly, to say nothing of "num", "countOf", etc.

[mikeb]

Andrea Williams wrote:

So if the TYPE in typeName doesn't indicate the data type, what does it
indicate. The example showed the following:

[Visual Basic]
Sub Write(doubleValue As Double);
Sub Write(singleValue As Single);
Sub Write(longValue As Long);
Sub Write(integerValue As Integer);
Sub Write(shortValue As Short);
[C#]
void Write(double doubleValue);
void Write(float floatValue);
void Write(long longValue);
void Write(int intValue);
void Write(short shortValue);

My resource:
http://msdn.microsoft.com/library/de...econfusion.asp

What am I misinterpreting here??
I was actually looking at a different part of the naming guidelines (the
"Parameter Naming Guidelines" page).

However, if you look closely at the "Avoiding Type Name Confusion" page
page you pointed out, the section you're citing is their example of what
*not* to do.

Right before the box with the example, there's a line that says;

------------------------------------------
Do not create language-specific method names, as in the following example.
------------------------------------------
Later they say that *if* you must include the data type in the parameter
name, you should use the 'universal' type names instead of the language
specific variants, since they differ by language sometimes (ie., float
in C# is Single in VB.NET)

In the "typeName" parameter example, they name the parameter that way
because the parameter to the GetType() method specifies the name of the
type desired. Note again, that the actual type of the "typeName"
parameter is System.String.

Andrea

I think you're getting a bit confused on what they're advocating - they
don't suggest prefixing parameter names with the type of the parameter.
Note that in the example they give, the typeName parameter is a string
type, but they didn't call it stringName.

The guidelines explicitly say:

============================================== ==
Use names that describe a parameter's meaning rather than names that
describe a parameter's type. Development tools should provide meaningful
information about a parameter's type. Therefore, a parameter's name can
be put to better use by describing meaning. Use type-based parameter
names sparingly and only where it is appropriate.
============================================== ==

--
mikeb

--
mikeb

[Dennis]

Can I suggest that you look at the following link. It is a combined
coding standard which we wrote based on the Microsoft .NET Guideline
and a C++ standard that Philips Medical Systems has been using for
years.

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

Dennis Doomen
Sioux TSO B.V.

mikeb <ma************@mailnull.com> wrote in message news:<ud**************@TK2MSFTNGP11.phx.gbl>...

Andrea Williams wrote:

So if the TYPE in typeName doesn't indicate the data type, what does it
indicate. The example showed the following:

[Visual Basic]
Sub Write(doubleValue As Double);
Sub Write(singleValue As Single);
Sub Write(longValue As Long);
Sub Write(integerValue As Integer);
Sub Write(shortValue As Short);
[C#]
void Write(double doubleValue);
void Write(float floatValue);
void Write(long longValue);
void Write(int intValue);
void Write(short shortValue);

My resource:
http://msdn.microsoft.com/library/de...econfusion.asp

What am I misinterpreting here??

I was actually looking at a different part of the naming guidelines (the
"Parameter Naming Guidelines" page).

However, if you look closely at the "Avoiding Type Name Confusion" page
page you pointed out, the section you're citing is their example of what
*not* to do.

Right before the box with the example, there's a line that says;

------------------------------------------
Do not create language-specific method names, as in the following example.
------------------------------------------
Later they say that *if* you must include the data type in the parameter
name, you should use the 'universal' type names instead of the language
specific variants, since they differ by language sometimes (ie., float
in C# is Single in VB.NET)

In the "typeName" parameter example, they name the parameter that way
because the parameter to the GetType() method specifies the name of the
type desired. Note again, that the actual type of the "typeName"
parameter is System.String.

Andrea

I think you're getting a bit confused on what they're advocating - they
don't suggest prefixing parameter names with the type of the parameter.
Note that in the example they give, the typeName parameter is a string
type, but they didn't call it stringName.

The guidelines explicitly say:

============================================== ==
Use names that describe a parameter's meaning rather than names that
describe a parameter's type. Development tools should provide meaningful
information about a parameter's type. Therefore, a parameter's name can
be put to better use by describing meaning. Use type-based parameter
names sparingly and only where it is appropriate.
============================================== ==

--
mikeb