C# coding style question

[Daniel O'Connell [C# MVP]]

Daniel.
I don't want my eyes to be jumping up and down, every time i see an
unknown
field.
If you want to do that, thats your prerogative.
Page long methods are not necessarily a bad thing.
Common guidelines? whose? there are so many of them.
Dot Net guidelines are not the best in my opinion.
Sharon.

If you are working alone, the guidelines are your own.
If you are working in a group, then the guidelines should be common to the
group.
But if you are working with the public, with anything that will be exposed
to one other person, I think you should strive to use the library guidelines
MS has already provided, everyone already knows them and implicitly
understands them. Serious deviation from those standards are usually enough
for me to decide to find a library which was written cleaner. Also, naming
like this carries the stigma of someone who isn't of the .NET mindset and
reduces faith in code in some cases. I don't want to be offensive, but when
you first examine a library the method names and parameters are going to be
the first thing you see. If you see java or C++ style naming, the first
thing that jumps to mind is that the library may have been developed like it
was java or C++, which as time and experiance has shown, is almost always a
bad thing(direct java ports of applications, in general, turn out to be
pretty off the mark). You get idiosyncratic behavior...things don't mesh
together. You get ".NET stuff" plus this very apparent, very ugly "other
stuff" mixed in your code. Even if the developer writes good, .NET code, the
method, class, namespace, property, and parameter names are still going to
make that class and its usage stand out. Its going to seriously disrupt the
flow of the code. Even your own code is going to exhibit this becase the
framework classes all follow a different convention:

System.String myString = "whatever";
myNamespace.MyClass myClassInstance = new MyClass();
myString.ToString();
myClassInstance.ToString();
myClassInstance.weirdMethodName();

As for unknown fields...I don't think I've ever worked on a method where I
didn't take the time before starting the method to consider the parameters,
even when modifying. A parameter defines, in part, the behavior of the
method, if you don't know the parameters you probably aren't going to get
the method implementation right. Its one of the first things I look at:
description, method name, return value, parameters, attributes, header
variables(those variables that were important enough or used enough to be
defined in the first..oh, 3-10 lines or so of the method, depending on
method length), then on through the code.

Which breaks common guidelines; other people have to deal with this, unlike
your fields. I would frown on this practice, personally. If a method is too
long to be able to glance and see which variables are parameters, then your
methods are too long.

One more thing...
I use p_paramName to distinguish between parameters and other method
fields:

//methods
public string MyMethod(int p_id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}

public class MyClass
{

//members
private int m_count = 0;
private string m_name = null;

//properties
public int Age
{
get{return m_count;}
set{m_count = value;}
}


//methods
public string MyMethod(int id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}


}


The c# code style guide that I follow suggests that class variables
(fields)
be coded with camel casing, like this:

int recordId;
string name;

It also suggests that variables within methods and method parameters use
camel casing, like this:

void SetName(int id, string newName)
{
recordId = id;
name = newName;
return;
}

This is all fine and dandy, but some of my methods are getting a bit
difficult to read. It's hard to differentiate between class fields (that
have a class-wide scope) and method variables (that have a method-wide
scope). I've started to use the "this" keyword with class variables,
example:

void SetName(int recordId, string name)
{
this.recordId = recordId;
this.name = name;
}

BUT, when you do that, you start to get really long lines of code. Here's
a
real line of my code that exhibits this problem:

this.currencyManager = (CurrencyManager)
this.grdPerson.BindingContext[this.dataView];

I'd love to know what other c# developers do.

Thanks!

Patrick

 

[Daniel O'Connell [C# MVP]]

You did not read my reply to n!, so here is the end of it:

As for p_ usage, think of it this way,
wouldn't you like it if parameters were colored in different color?
It helps when revising a method after, say, 1 year.

Personally, no, I'd rather parameters weren't colored and they were
unprefixed. 90%+ of the usage of a parameter is *outside* the method.
Coloring and prefixing helps, maybe, for the minority of cases, IMHO.

Daniel.
I don't want my eyes to be jumping up and down, every time i see an
unknown
field.
If you want to do that, thats your prerogative.
Page long methods are not necessarily a bad thing.
Common guidelines? whose? there are so many of them.
Dot Net guidelines are not the best in my opinion.
Sharon.

If you are working alone, the guidelines are your own.
If you are working in a group, then the guidelines should be common to
the
group.
But if you are working with the public, with anything that will be
exposed
to one other person, I think you should strive to use the library guidelines
MS has already provided, everyone already knows them and implicitly
understands them. Serious deviation from those standards are usually enough
for me to decide to find a library which was written cleaner. Also,
naming
like this carries the stigma of someone who isn't of the .NET mindset and
reduces faith in code in some cases. I don't want to be offensive, but when
you first examine a library the method names and parameters are going to be
the first thing you see. If you see java or C++ style naming, the first
thing that jumps to mind is that the library may have been developed like it
was java or C++, which as time and experiance has shown, is almost always a
bad thing(direct java ports of applications, in general, turn out to be
pretty off the mark). You get idiosyncratic behavior...things don't mesh
together. You get ".NET stuff" plus this very apparent, very ugly "other
stuff" mixed in your code. Even if the developer writes good, .NET code, the
method, class, namespace, property, and parameter names are still going
to
make that class and its usage stand out. Its going to seriously disrupt the
flow of the code. Even your own code is going to exhibit this becase the
framework classes all follow a different convention:

System.String myString = "whatever";
myNamespace.MyClass myClassInstance = new MyClass();
myString.ToString();
myClassInstance.ToString();
myClassInstance.weirdMethodName();

As for unknown fields...I don't think I've ever worked on a method where
I
didn't take the time before starting the method to consider the parameters,
even when modifying. A parameter defines, in part, the behavior of the
method, if you don't know the parameters you probably aren't going to get
the method implementation right. Its one of the first things I look at:
description, method name, return value, parameters, attributes, header
variables(those variables that were important enough or used enough to be
defined in the first..oh, 3-10 lines or so of the method, depending on
method length), then on through the code.

message Which breaks common guidelines; other people have to deal with this,
unlike
your fields. I would frown on this practice, personally. If a method
is
too
long to be able to glance and see which variables are parameters, then
your
methods are too long.

One more thing...
I use p_paramName to distinguish between parameters and other method
fields:

//methods
public string MyMethod(int p_id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}

public class MyClass
{

//members
private int m_count = 0;
private string m_name = null;

//properties
public int Age
{
get{return m_count;}
set{m_count = value;}
}


//methods
public string MyMethod(int id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}


}


The c# code style guide that I follow suggests that class variables
(fields)
be coded with camel casing, like this:

int recordId;
string name;

It also suggests that variables within methods and method
parameters
use
camel casing, like this:

void SetName(int id, string newName)
{
recordId = id;
name = newName;
return;
}

This is all fine and dandy, but some of my methods are getting a
bit
difficult to read. It's hard to differentiate between class fields
(that
have a class-wide scope) and method variables (that have a method-wide
scope). I've started to use the "this" keyword with class
variables,
example:

void SetName(int recordId, string name)
{
this.recordId = recordId;
this.name = name;
}

BUT, when you do that, you start to get really long lines of code.
Here's
a
real line of my code that exhibits this problem:

this.currencyManager = (CurrencyManager)
this.grdPerson.BindingContext[this.dataView];

I'd love to know what other c# developers do.

Thanks!

Patrick

 

[Sharon]

You did not read my reply to n!, so here is the end of it:

But after all, unfortunately i will have to agree with you.
Because i do have to conform with the API i'm using.

As for p_ usage, think of it this way,
wouldn't you like it if parameters were colored in different color?
It helps when revising a method after, say, 1 year.

Daniel.
I don't want my eyes to be jumping up and down, every time i see an
unknown
field.
If you want to do that, thats your prerogative.
Page long methods are not necessarily a bad thing.
Common guidelines? whose? there are so many of them.
Dot Net guidelines are not the best in my opinion.
Sharon.

If you are working alone, the guidelines are your own.
If you are working in a group, then the guidelines should be common to the
group.
But if you are working with the public, with anything that will be exposed
to one other person, I think you should strive to use the library guidelines
MS has already provided, everyone already knows them and implicitly
understands them. Serious deviation from those standards are usually enough
for me to decide to find a library which was written cleaner. Also, naming
like this carries the stigma of someone who isn't of the .NET mindset and
reduces faith in code in some cases. I don't want to be offensive, but when
you first examine a library the method names and parameters are going to be
the first thing you see. If you see java or C++ style naming, the first
thing that jumps to mind is that the library may have been developed like it
was java or C++, which as time and experiance has shown, is almost always a
bad thing(direct java ports of applications, in general, turn out to be
pretty off the mark). You get idiosyncratic behavior...things don't mesh
together. You get ".NET stuff" plus this very apparent, very ugly "other
stuff" mixed in your code. Even if the developer writes good, .NET code, the
method, class, namespace, property, and parameter names are still going to
make that class and its usage stand out. Its going to seriously disrupt the
flow of the code. Even your own code is going to exhibit this becase the
framework classes all follow a different convention:

System.String myString = "whatever";
myNamespace.MyClass myClassInstance = new MyClass();
myString.ToString();
myClassInstance.ToString();
myClassInstance.weirdMethodName();

As for unknown fields...I don't think I've ever worked on a method where I
didn't take the time before starting the method to consider the parameters,
even when modifying. A parameter defines, in part, the behavior of the
method, if you don't know the parameters you probably aren't going to get
the method implementation right. Its one of the first things I look at:
description, method name, return value, parameters, attributes, header
variables(those variables that were important enough or used enough to be
defined in the first..oh, 3-10 lines or so of the method, depending on
method length), then on through the code.

Which breaks common guidelines; other people have to deal with this, unlike
your fields. I would frown on this practice, personally. If a method is too
long to be able to glance and see which variables are parameters, then your
methods are too long.

One more thing...
I use p_paramName to distinguish between parameters and other method
fields:

//methods
public string MyMethod(int p_id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}

public class MyClass
{

//members
private int m_count = 0;
private string m_name = null;

//properties
public int Age
{
get{return m_count;}
set{m_count = value;}
}


//methods
public string MyMethod(int id)
{
string tempName = null;
tempName = somehtin.......

return tempName;
}


}


The c# code style guide that I follow suggests that class variables
(fields)
be coded with camel casing, like this:

int recordId;
string name;

It also suggests that variables within methods and method parameters use
camel casing, like this:

void SetName(int id, string newName)
{
recordId = id;
name = newName;
return;
}

This is all fine and dandy, but some of my methods are getting a bit
difficult to read. It's hard to differentiate between class fields (that
have a class-wide scope) and method variables (that have a method-wide
scope). I've started to use the "this" keyword with class variables,
example:

void SetName(int recordId, string name)
{
this.recordId = recordId;
this.name = name;
}

BUT, when you do that, you start to get really long lines of code. Here's
a
real line of my code that exhibits this problem:

this.currencyManager = (CurrencyManager)
this.grdPerson.BindingContext[this.dataView];

I'd love to know what other c# developers do.

Thanks!

Patrick

 

[Sharon]

My point is that you don't need prefix's to have this ability. Nor does it
matter in the grand scheme of things

Think of it this way,
wouldn't you like it if parameters were colored in different color?
It helps when revising a method after, say, 1 year.

No, I don't. I do in C++, but not in C#. At least, not anymore. I used to
when I first started C# and I even tried the simple _ prefix (at the time I
was loathe to try programming without prefix's . But in the end I found
that disgarding all prefixes left me with cleaner and easier to understand
code.

I think it's wrong.
A class member is not an internal member is not a parameter.
I use prefixes only for params and class members.

This is all IMHO, coding style is an unfortunate area where few people
agree. And those that don't agree defend their own ideas religiously. So I'm
not actually saying you're wrong at all, just adding my own thoughts

n!

We agree to disagree

 

[Guest]

Patrick

I follow a few simple rules that minimise this problem

Where you have use a method to SET as member variable, this should probably be a PROPERTY. in the property (C#) you have value, which is the incoming parameter. This way, you only ever have one place (maybe also in the contructor) where you actually reference the member variable, and therefore limit the possibility of having a parameter with the same name as a member variable. All access to member variables should run through properties.. (Yes, there are a few cases where this is not practical, but it does make things easier when you want to implement property changed events...

Example

public class MyClas

private int myIntValue

public MyClass(

myIntValue = 0


public int MyIntValu

ge

return myIntValue

se

myIntValue = value



public int DoSomething(int myIntValue

return MyIntValue * myIntValue




----- Patrick wrote: ----

The c# code style guide that I follow suggests that class variables (fields
be coded with camel casing, like this

int recordId
string name

It also suggests that variables within methods and method parameters us
camel casing, like this

void SetName(int id, string newName

recordId = id
name = newName
return


This is all fine and dandy, but some of my methods are getting a bi
difficult to read. It's hard to differentiate between class fields (tha
have a class-wide scope) and method variables (that have a method-wid
scope). I've started to use the "this" keyword with class variables
example

void SetName(int recordId, string name

this.recordId = recordId
this.name = name


BUT, when you do that, you start to get really long lines of code. Here's
real line of my code that exhibits this problem

this.currencyManager = (CurrencyManager
this.grdPerson.BindingContext[this.dataView]

I'd love to know what other c# developers do

Thanks

Patric

 

[skc]

Hi

As for p_ usage, think of it this way,
wouldn't you like it if parameters were colored in different color?
It helps when revising a method after, say, 1 year.

I am a newbie and currently am learning the C# language. I don't know
whether I am understanding correctly. But I don't see any reason why
parameters are given the same names as class variables. I agree with Sharon
that differentiating parameters from variable-names make the codes easier to
understand. Also when I code I usually differentiate variables from Table
fields (in the database) by putting a prefix to variables. I say this from
a newbie's point of view.

Regards

 

[Daniel O'Connell [C# MVP]]

Hi


I am a newbie and currently am learning the C# language. I don't know
whether I am understanding correctly. But I don't see any reason why
parameters are given the same names as class variables. I agree with
Sharon
that differentiating parameters from variable-names make the codes easier
to
understand. Also when I code I usually differentiate variables from Table
fields (in the database) by putting a prefix to variables. I say this
from
a newbie's point of view.

public void MyMethod(int p_myParameter)
{
//your code
}
Consider this...you have maybe 20 lines of code in existance which has *any*
reason to care to distinguish between a parameter and a local variable.
Every other line is going to use(either via intellisense or named
parameters) that parameter by
MyMethod(10)...that p_ basically just adds extra text to read and obfuscates
the inherent meaning given to the parameter by its name, its already pretty
damn obviously a parameter. Its the same as I don't need to see
method_MyMethod because any idiot can tell its a method. Convience for such
a small bit of code, and a convience I question personally, is not something
I think is worth inconvenicing the potentially hundreds or thousands of
lines that use it on the other end. Granted, it is an opinon and not
everyone shares it, however there is a great deal of important in
maintaining common guidelines. Prefixes are so alien to 90% of .NET code
that they make your code not only look ugly(prefixes in general are always
ugly, IMHO), but reduces readbility for everyone else. I will almost always
drop a library(wont' buy it, won't even use it if its open source) if I find
m_ or p_ or any of those prefixes in public or protected portion of the code
simply because it interrupts my reading of the code and doesn't mesh well. A
library that makes life easier isn't worth it if its internal interface
forces me to work in a different way(there are other situations than just
prefixing, for example people using copy constructors or using language
specifc patterns instead of BCL ones) I'd rather not see its usage privatly
in OSS either, however I complain less about private prefixing, as a
consumer doesn't have to worry about what someone did internally.

 

[Bruno Jouhier [MVP]]

I am not a newbie and I agree with your point.
There is a chance of name collision between a parameter and a field,
especially in constructors.
So, the trick that we are using is to prefix private stuff (fields and
methods) by an underscore. As we impose that fields be private in all our
code, they get automatically prefixed by an underscore and we avoid these
name collisions.

Note: as others have mentioned, this prefixing scheme has a few other
advantages:
* intellisense: _ gives you the list of private fields (and methods in our
case).
* it does not add much extra typing, and it is not too ugly (less than
prefixes like p_ or m_ that are at odds with general .NET naming
guidelines -- capitalization rather than underscores to separate words).
* compatibility with .NET naming guidelines. If you restrict this underscore
prefix to private stuff, you can still use the .NET naming guidelines for
all the rest (and the guidelines give you this freedom for your private
stuff). On the other hand, if you use a p_ prefix for parameters you won't
follow the guidelines and your APIs documentation/intellisense will feel
"non standard".
* it is fairly common. I have seen it in a number of places, including .NET
source code that MS made available publicly.

Bruno.

 

[Jon Skeet [C# MVP]]

* it is fairly common. I have seen it in a number of places, including .NET
source code that MS made available publicly.

Unfortunately that's the case for any number of conventions. Just
looking at some of the Rotor classes, it's easy to see:

m_memberName (eg Char)
_memberName (eg Console)
memberName (eg DateTime)

 

[Bruno Jouhier [MVP]]

Unfortunately that's the case for any number of conventions. Just
looking at some of the Rotor classes, it's easy to see:

m_memberName (eg Char)
_memberName (eg Console)
memberName (eg DateTime)

Good point
Bruno.

 

[Daniel O'Connell [C# MVP]]

Unfortunately that's the case for any number of conventions. Just
looking at some of the Rotor classes, it's easy to see:

m_memberName (eg Char)
_memberName (eg Console)
memberName (eg DateTime)

Part of waht makes rotor interesting is that it was written while the
platform evolved, obviously. I wonder if we were to take the classes with a
given convention and determine when they were written if a pattern would
emerge or if it is entirely based on *who* wrote it.

 

[Jon Skeet [C# MVP]]

Part of waht makes rotor interesting is that it was written while the
platform evolved, obviously. I wonder if we were to take the classes with a
given convention and determine when they were written if a pattern would
emerge or if it is entirely based on *who* wrote it.

I suspect it really is just a case of who wrote it. I'm pretty sure
I've seen a mixture of styles in MSDN too.

 

[Daniel O'Connell [C# MVP]]

I suspect it really is just a case of who wrote it. I'm pretty sure
I've seen a mixture of styles in MSDN too.

I have as well, however it isn't certain as to who wrote them or when.
A*lot* of the m_ prefixed code I see is sourced from people who either
havn't given up C++ yet or are just starting on it. I suppose its a habit
that is hard to break if you've been using it for years.
I still see m_ prefixed code in MSDN mag now and then, infact I think the
newest issue had a C# 2.0 example using the m_ prefix(which irks me to no
end...IMHO, someone who is writing for a magazine or other publication
should atleast try to follow the widest convention, which I think is no
prefix at all).

I am curious about the trends primarily because of the age of the source
base and the fact that it was written while the transition between hungarian
and camel\Pascal casing was coming into the framework, the earliest files in
rotor were probably written 5 or 6 years ago and I do wonder if there are
trends that can be seen...perhaps something like a code 'Sociology'.
Conventions and the code written are, after all, in many cases social
things, probably prone to the same forces that affect fashion and
culture...just on a considerably smaller scale.

I dunno, its pretty late and I'm probably rambling and not realizing it at
this point. I think I'll end this here.

 

[Bruno Jouhier [MVP]]

I agree that we all should use conventions.

I agree too, even if they are not the ones we would have chosen...

But who made Dot Net convention anyway?

Microsoft did it.
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp

Who decided to remove prefixes? and why?
I like prefixes.

If you are talking about the famous Hungarian notations, you will find lots
of contradictors, and I'll be one of them. If you are talking about a single
underscore prefix on private fields, you will get some support (mine
included).

They make the code more clear.
They identify the scope of a field, instantly.

There is a rather widespread agreement on the fact that fields should always
be private. If you follow this rule, there is no need to identify the scope
of fields! Which does not mean that it is not interesting to differentiate
fields from parameters and local variables, with a prefix (I support this
view), but this is different from "scope of fields".

Ugly or not is a matter of opinion.

Yes, but you are being subjective too when you say "I like prefixes". The
people who define the "conventions" have to take a subjective stand at some
point, because they are dealing with complex issues that include "liking or
not", "looking nice or ugly". And they have decided to remove prefixes from
all non private APIs (with a few exceptions, for example the I prefix on
interfaces). They did not fully specify what you should do with private
stuff, so there is some room for debate around prefix vs. no prefix here.
Also, there seems to be limited room for prefix on class names. For example,
all the XML related classes are prefixed by Xml in the framework, which
makes a lot of sense (more than calling them just Document, Element, Node,
etc., which is what the basic naming rules seem to favor).

Bruno.

I have as well, however it isn't certain as to who wrote them or when.
A*lot* of the m_ prefixed code I see is sourced from people who either
havn't given up C++ yet or are just starting on it. I suppose its a habit
that is hard to break if you've been using it for years.
I still see m_ prefixed code in MSDN mag now and then, infact I think the
newest issue had a C# 2.0 example using the m_ prefix(which irks me to no
end...IMHO, someone who is writing for a magazine or other publication
should atleast try to follow the widest convention, which I think is no
prefix at all).

I am curious about the trends primarily because of the age of the source
base and the fact that it was written while the transition between hungarian
and camel\Pascal casing was coming into the framework, the earliest

files

 

[Sharon]

I agree that we all should use conventions.
But who made Dot Net convention anyway?
Who decided to remove prefixes? and why?
I like prefixes.
They make the code more clear.
They identify the scope of a field, instantly.
Ugly or not is a matter of opinion.

I suspect it really is just a case of who wrote it. I'm pretty sure
I've seen a mixture of styles in MSDN too.

I have as well, however it isn't certain as to who wrote them or when.
A*lot* of the m_ prefixed code I see is sourced from people who either
havn't given up C++ yet or are just starting on it. I suppose its a habit
that is hard to break if you've been using it for years.
I still see m_ prefixed code in MSDN mag now and then, infact I think the
newest issue had a C# 2.0 example using the m_ prefix(which irks me to no
end...IMHO, someone who is writing for a magazine or other publication
should atleast try to follow the widest convention, which I think is no
prefix at all).

I am curious about the trends primarily because of the age of the source
base and the fact that it was written while the transition between hungarian
and camel\Pascal casing was coming into the framework, the earliest files in
rotor were probably written 5 or 6 years ago and I do wonder if there are
trends that can be seen...perhaps something like a code 'Sociology'.
Conventions and the code written are, after all, in many cases social
things, probably prone to the same forces that affect fashion and
culture...just on a considerably smaller scale.

I dunno, its pretty late and I'm probably rambling and not realizing it at
this point. I think I'll end this here.

 

[Joerg Jooss]

The c# code style guide that I follow suggests that class variables
(fields) be coded with camel casing, like this:

int recordId;
string name;

It also suggests that variables within methods and method parameters
use camel casing, like this:

void SetName(int id, string newName)
{
recordId = id;
name = newName;
return;
}

This is all fine and dandy, but some of my methods are getting a bit
difficult to read. It's hard to differentiate between class fields
(that have a class-wide scope) and method variables (that have a
method-wide scope). I've started to use the "this" keyword with class
variables, example:

void SetName(int recordId, string name)
{
this.recordId = recordId;
this.name = name;
}

BUT, when you do that, you start to get really long lines of code.
Here's a real line of my code that exhibits this problem:

this.currencyManager = (CurrencyManager)
this.grdPerson.BindingContext[this.dataView];

I'd love to know what other c# developers do.

I use "this", but only for accessing fields, and add a property for each
field that needs to be exposed to clients. It all boils down to

class Record {
private int id;
private string name;

public int Id {
get { return this.id; }
set { this.id = value; }
}

public string Name {
get { return this.name; }
set { this.name = value; }
}

public override string ToString() {
return String.Format("{0} [{1}]", Name, Id);
}
}

Thus, "this" will only appear in property definitions or in methods that
access strictly private attributes (i.e. that are not to be exposed using
properties).

Cheers,

 

[skc]

I am surprised C# allows a sort of 'duplicate' names within a method. Even
though allowed, my contention is that parameters should be distinguished
from variables, so that we can easily tell straightway which is which. it's
unlikely then, we will make mistake in this area even if we switch our minds
to "lazy" mode. Since you pointed out the webpage on the guideline (and
I am reading it for the first time) that parameters shouldn't have prefix, I
can accept that. In which case, it's private variables then that must have
a prefix, or like you suggest an underscore.

Then again, for those who don't intend to sell or give away their classes,
I guess it doesn't matter that much..... . yea, I know it's better to
do so....


Regards
Skc

 

[skc]

Thanks for your agreement and your explanation. Actually, I am surprised
somewhat that C# allows this sort of 'duplicate' names within a method.
Just read the naming guidelines you mentioned elsewhere (and I am reading it
for the first time) that parameters shouldn't have prefix - I can accept
that. In which case, it's private variables then that should have a
prefix, or like you suggest an _.

Then again, for those who don't intend to sell or give away their classes,
I guess it shouldn't matter that much whether or not MS standards are
followed as long as there is a kind of internal standards within the
organisation..... .

Regards
Skc

 

[skc]

Hullo Bruno

Thanks for your agreement and your explanation. Actually, I am surprised
somewhat that C# allows this sort of 'duplicate' names within a method. Just
read the naming guidelines you mentioned elsewhere (and I am reading it for
the first time) that parameters shouldn't have prefix - I can accept that.
In which case, it's private variables then that should have a prefix, or
like you suggest an _.

Then again, for those who don't intend to sell or give away their classes,
I guess it shouldn't matter that much whether or not MS standards are
followed as long as there is a kind of internal standards within the
organisation..... .

Regards
Skc
[ This posting was posted to the wrong place twice and deleted - apologize
if anyone sees 3 similar postings ].