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

C# coding style question

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
39 Replies


P: n/a
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;
}
}
"Patrick" <ne*******@devzoo.com> wrote in message news:Ox*************@TK2MSFTNGP10.phx.gbl...
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

Nov 16 '05 #2

P: n/a
Patrick wrote:
[...]
I've started to use the "this" keyword with class variables,
[...]


Just curious about why you feel the need to do the above? Could it be
because your methods are too long?

Personally, I don't see a need for any such thing, except in the case
where the parameter name is the same as that of the member variable.
Nov 16 '05 #3

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

"Claus Konrad" <cl***@whoknows.it> wrote in message
news:OG****************@TK2MSFTNGP11.phx.gbl...
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;
}
}
"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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

Nov 16 '05 #4

P: n/a
Hi Patrick,

"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
The c# code style guide that I follow suggests that class variables (fields) be coded with camel casing, like this:

int recordId;
string name; <snip> I'd love to know what other c# developers do.

Thanks!


For private class fields and constants I use camel-casing with an
underscore prefix:

string _someData;
const string _SOME_CONSTANT = "foo";

I like the single underscore prefix for private fields for two reasons:

1. I'm lazy and using a prefix longer than 1 character seems
wasteful.
2. If I type "_" and then CTRL+SPACE, I get a list of the private
fields in the current class.

Just my $0.02.

Regards,
Daniel
Nov 16 '05 #5

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

"Sharon" <ta*******@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...
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;
}

"Claus Konrad" <cl***@whoknows.it> wrote in message
news:OG****************@TK2MSFTNGP11.phx.gbl...
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;
}
}
"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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


Nov 16 '05 #6

P: n/a
I prefer Hungarian over camel casing.
"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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

Nov 16 '05 #7

P: n/a

"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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.

Personally, I don't use any prefixes. I, however, don't use this unless I
happen to have a collision with a local or parameter name. IMHO, using this
just to differentiate between the two is going to lead to readbility
problems eventually.
Thanks!

Patrick

Nov 16 '05 #8

P: n/a
-----Original Message-----
For private class fields and constants I use camel- casing with anunderscore prefix:

string _someData;
const string _SOME_CONSTANT = "foo";

I like the single underscore prefix for private fields for two reasons:
1. I'm lazy and using a prefix longer than 1 character seemswasteful.
2. If I type "_" and then CTRL+SPACE, I get a list of the privatefields in the current class.

Just my $0.02.

Regards,
Daniel


I also prefer this style of prefixing _ (under score) to
private fields.

I use camelCasing with local variables and
HungarianNotation with Method Names, Property Names and
Class Names.

--
Cheers,
Rahul Anand
Nov 16 '05 #9

P: n/a

"Rahul Anand" <ra************@rediffmail.com> wrote in message
news:20****************************@phx.gbl...
-----Original Message-----
For private class fields and constants I use camel- casing with an
underscore prefix:

string _someData;
const string _SOME_CONSTANT = "foo";

I like the single underscore prefix for private

fields for two reasons:

1. I'm lazy and using a prefix longer than 1

character seems
wasteful.
2. If I type "_" and then CTRL+SPACE, I get a

list of the private
fields in the current class.

Just my $0.02.

Regards,
Daniel


I also prefer this style of prefixing _ (under score) to
private fields.

I use camelCasing with local variables and
HungarianNotation with Method Names, Property Names and
Class Names.


I take it you mean PascalCasing, hungarian notation is the practice of
prefixing the variable\field with a location identifier(g_ for global, m_for
member) and other information based on type or intent(mstr_ for a member
string, for example).
--
Cheers,
Rahul Anand

Nov 16 '05 #10

P: n/a
-----Original Message-----

"Rahul Anand" <ra************@rediffmail.com> wrote in
I also prefer this style of prefixing _ (under score) to
private fields.

I use camelCasing with local variables and
HungarianNotation with Method Names, Property Names and
Class Names.
I take it you mean PascalCasing, hungarian notation is

the practice ofprefixing the variable\field with a location identifier (g_ for global, m_formember) and other information based on type or intent (mstr_ for a memberstring, for example).

--
Cheers,
Rahul Anand


Right Daniel, it is PascalCasing. Thanks for correction.
Nov 16 '05 #11

P: n/a

"Rahul Anand" <ra************@rediffmail.com> wrote in message
news:1f****************************@phx.gbl...
-----Original Message-----

"Rahul Anand" <ra************@rediffmail.com> wrote in
I also prefer this style of prefixing _ (under score) to
private fields.

I use camelCasing with local variables and
HungarianNotation with Method Names, Property Names and
Class Names.
I take it you mean PascalCasing, hungarian notation is

the practice of
prefixing the variable\field with a location identifier

(g_ for global, m_for
member) and other information based on type or intent

(mstr_ for a member
string, for example).

--
Cheers,
Rahul Anand


Right Daniel, it is PascalCasing. Thanks for correction.

Just making sure I wasn't forgetting my terms all of a sudden, ;).

Nov 16 '05 #12

P: n/a
Patrick <ne*******@devzoo.com> 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 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.


That *usually* suggests to me that perhaps the methods are too long, or
the classes are too large. It should always be fairly easy to
understand which parts of state logically belong to the method and
which to the class.

Like Daniel, I don't use any prefixes, and I don't use "this" unless I
need to in order to disambiguate - which is usually in a constructor.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #13

P: n/a
n!
> Like Daniel, I don't use any prefixes, and I don't use "this" unless I
need to in order to disambiguate - which is usually in a constructor.


Add me to this list too. Like Daniel and Jon, I don't use any prefixes and
I've rarely needed to use 'this', except in constructors.. :)

n!
Nov 16 '05 #14

P: n/a
We prefix the field name by an underscore:

int _recordId;

Actually, we prefix everything that's private (our conventions enforce that
all fields be private) by an underscore.
This convention is simple and concise and the big advantage is that you
immediately make the distinction between private stuff (fields and private
methods) and the rest.

Bruno.

"Patrick" <ne*******@devzoo.com> a écrit dans le message de
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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

Nov 16 '05 #15

P: n/a
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.
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uP*************@tk2msftngp13.phx.gbl...
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.

"Sharon" <ta*******@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...
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;
}

"Claus Konrad" <cl***@whoknows.it> wrote in message
news:OG****************@TK2MSFTNGP11.phx.gbl...
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;
}
}
"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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



Nov 16 '05 #16

P: n/a
n!
> I don't want my eyes to be jumping up and down, every time i see an
unknown
field.
I'm not sure why you would have to jump up and down, there should never be
an unknown field. The immediate variables you are using are either member
variables of your class, parameters or method local variables. They can't be
anything else, if you can see the method signature you can surely work it
out from that. This really shouldn't be a problem.
Page long methods are not necessarily a bad thing.
If they're interfering with your ability to follow code they are ;) There
are some things that just end up being long and, if so, there's not much
else you can do (though, for me, such methods are extremely rare). But even
long methods shouldn't make it difficult to determine where the variable
came from. Shorter methods should be the goal rather than long ones :)
Common guidelines? whose? there are so many of them.
Dot Net guidelines are not the best in my opinion.


Whether you like them or not, the .NET framework guidelines are used by the
standard API. Using another set of guidelines means your code will appear
alien compared to the objects provided with it.

I've tried a number of different coding styles with C# and in the end I've
ended up using the guidelines provided by the framework. Not only because it
matches the API, but it just ended up working better with C# (IMHO of course
:)

n!

Nov 16 '05 #17

P: n/a
My point is simple n!, when looking at a field i want to know it's a
parameter.
Do you mark member fields with m_? same thing.
I don't have many long methods, but even in short methods, p_ helps.
It's like syntax coloring, the parameters immediately identify themselves,
even at a quick glance.
Whether you like them or not, the .NET framework guidelines are used by the standard API. Using another set of guidelines means your code will appear
alien compared to the objects provided with it.
Good point.
I follow all of the .NET framework guidelines, with 2 exceptions:
1. p_paramName which makes my life easier.
2. i use camelCase for method names and name spaces.
This is a Java legacy and i like it.
Unfortunately microsoft have made the mistake of using capital
for namespace, class and method.
Which one is more clear to you?
a. NameSpace.NameSpace.Class.Method
b. nameSpace.nameSpace.Class.method
Tough choice?

But after all, unfortunately i will have to agree with you.
Because i do have to conform with the API i'm using.
"n!" <nf********@nomailplease.com> wrote in message
news:Ot**************@TK2MSFTNGP09.phx.gbl...
I don't want my eyes to be jumping up and down, every time i see an

unknown
field.


I'm not sure why you would have to jump up and down, there should never be
an unknown field. The immediate variables you are using are either member
variables of your class, parameters or method local variables. They can't

be anything else, if you can see the method signature you can surely work it
out from that. This really shouldn't be a problem.
Page long methods are not necessarily a bad thing.
If they're interfering with your ability to follow code they are ;) There
are some things that just end up being long and, if so, there's not much
else you can do (though, for me, such methods are extremely rare). But

even long methods shouldn't make it difficult to determine where the variable
came from. Shorter methods should be the goal rather than long ones :)
Common guidelines? whose? there are so many of them.
Dot Net guidelines are not the best in my opinion.
Whether you like them or not, the .NET framework guidelines are used by

the standard API. Using another set of guidelines means your code will appear
alien compared to the objects provided with it.

I've tried a number of different coding styles with C# and in the end I've
ended up using the guidelines provided by the framework. Not only because it matches the API, but it just ended up working better with C# (IMHO of course :)

n!

Nov 16 '05 #18

P: n/a
Sharon <ta*******@hotmail.com> wrote:
2. i use camelCase for method names and name spaces.
This is a Java legacy and i like it.


I try to ignore conventions from other languages when I start learning
a new one. If my conventions look too much like the ones I'd use in
Java, I'll start writing code as if it's Java, which is a bad thing...
(Not that Java is a bad thing, but you should never start using the
idioms of one language in another - always be aware of what you're
writing in.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #19

P: n/a
n!
> My point is simple n!, when looking at a field i want to know it's a
parameter.
My point is that you don't need prefix's to have this ability. Nor does it
matter in the grand scheme of things :)
Do you mark member fields with m_? same thing.


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.

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!
Nov 16 '05 #20

P: n/a

"Sharon" <ta*******@hotmail.com> wrote in message
news:uZ*************@TK2MSFTNGP11.phx.gbl...
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.
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uP*************@tk2msftngp13.phx.gbl...
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.

"Sharon" <ta*******@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...
> 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;
> }
>
> "Claus Konrad" <cl***@whoknows.it> wrote in message
> news:OG****************@TK2MSFTNGP11.phx.gbl...
> 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;
> }
>
>
> }
>
>
> "Patrick" <ne*******@devzoo.com> wrote in message
> news:Ox*************@TK2MSFTNGP10.phx.gbl...
>> 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
>>
>>
>
>



Nov 16 '05 #21

P: n/a
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 O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eY**************@TK2MSFTNGP12.phx.gbl...
"Sharon" <ta*******@hotmail.com> wrote in message
news:uZ*************@TK2MSFTNGP11.phx.gbl...
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.

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uP*************@tk2msftngp13.phx.gbl...
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.

"Sharon" <ta*******@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...
> 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;
> }
>
> "Claus Konrad" <cl***@whoknows.it> wrote in message
> news:OG****************@TK2MSFTNGP11.phx.gbl...
> 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;
> }
>
>
> }
>
>
> "Patrick" <ne*******@devzoo.com> wrote in message
> news:Ox*************@TK2MSFTNGP10.phx.gbl...
>> 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
>>
>>
>
>



Nov 16 '05 #22

P: n/a

"n!" <nf********@nomailplease.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
My point is simple n!, when looking at a field i want to know it's a
parameter.
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.
Do you mark member fields with m_? same thing.
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 :)
Nov 16 '05 #23

P: n/a

"Sharon" <ta*******@hotmail.com> wrote in message
news:uq**************@TK2MSFTNGP09.phx.gbl...
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.


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 O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eY**************@TK2MSFTNGP12.phx.gbl...

"Sharon" <ta*******@hotmail.com> wrote in message
news:uZ*************@TK2MSFTNGP11.phx.gbl...
> 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.
>
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:uP*************@tk2msftngp13.phx.gbl...
>> 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.
>>
>> "Sharon" <ta*******@hotmail.com> wrote in message
>> news:eD**************@TK2MSFTNGP10.phx.gbl...
>> > 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;
>> > }
>> >
>> > "Claus Konrad" <cl***@whoknows.it> wrote in message
>> > news:OG****************@TK2MSFTNGP11.phx.gbl...
>> > 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;
>> > }
>> >
>> >
>> > }
>> >
>> >
>> > "Patrick" <ne*******@devzoo.com> wrote in message
>> > news:Ox*************@TK2MSFTNGP10.phx.gbl...
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 16 '05 #24

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

Nov 16 '05 #25

P: n/a
Thanks to all for the great feedback.

From all the posts, the 2 ideas that appeal to me the most are:
1) Prefix class fields with a single underscore to differentiate them from
method variabes, like so:

int _someValue;
void MyMethod(int someValue)
{
int someOtherValue;
_someValue = someValue;
}

or, 2) Make no effort to differentiate the two, but just keep methods short
enough that it's easy to keep track of which variables are which. In the
case of parameters that have the same names as class fields, use the "this"
keyword for the class fields. Like so:

int someValue;
void MyMethod(int someValue)
{
int someOtherValue;
this.someValue = someValue;
}

And after considering the matter and reading all your ideas, I've decided on
choice #2, at least for now.

Thanks again!

Patrick
"Patrick" <ne*******@devzoo.com> wrote in message
news:Ox*************@TK2MSFTNGP10.phx.gbl...
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

Nov 16 '05 #26

P: n/a
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
Nov 16 '05 #27

P: n/a

"skc" <an*******@yahoo.com.sg> wrote in message
news:Ot**************@tk2msftngp13.phx.gbl...
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.

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

Nov 16 '05 #28

P: n/a
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.
"skc" <an*******@yahoo.com.sg> a écrit dans le message de
news:Ot**************@tk2msftngp13.phx.gbl...
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

Nov 16 '05 #29

P: n/a
Bruno Jouhier [MVP] <bj******@club-internet.fr> wrote:
* 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)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #30

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> a écrit dans le message de
news:MP************************@msnews.microsoft.c om...
Bruno Jouhier [MVP] <bj******@club-internet.fr> wrote:
* 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)


Good point :-)
Bruno.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #31

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Bruno Jouhier [MVP] <bj******@club-internet.fr> wrote:
* 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)

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #32

P: n/a
Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #33

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:
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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #34

P: n/a
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.
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eD**************@TK2MSFTNGP12.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:
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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 16 '05 #35

P: n/a

"Sharon" <ta*******@hotmail.com> a écrit dans le message de
news:O8**************@tk2msftngp13.phx.gbl...
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/de...guidelines.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.


"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eD**************@TK2MSFTNGP12.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:
> 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. 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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 16 '05 #36

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

--
Joerg Jooss
jo*********@gmx.net

Nov 16 '05 #37

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


Bruno Jouhier [MVP] <bj******@club-internet.fr> wrote in message
news:Od**************@tk2msftngp13.phx.gbl...

"Sharon" <ta*******@hotmail.com> a écrit dans le message de
news:O8**************@tk2msftngp13.phx.gbl...
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/de...us/cpgenref/ht
ml/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.


"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eD**************@TK2MSFTNGP12.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:
>> 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.
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.

>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Nov 16 '05 #38

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

Nov 16 '05 #39

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

Nov 16 '05 #40

This discussion thread is closed

Replies have been disabled for this discussion.