C# coding style question

[Patrick]

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

 

[Claus Konrad]

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;
}


}

 

[C# Learner]

[...]
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.

 

[Daniel Pratt]

Hi Patrick,

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

int recordId;
string name;

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

 

[Sharon]

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;
}


}

 

[Daniel O'Connell [C# MVP]]

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

 

[Anthony Yio]

I prefer Hungarian over camel casing.

 

[Daniel O'Connell [C# MVP]]

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.

 

[Rahul Anand]

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

 

[Daniel O'Connell [C# MVP]]

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

 

[Rahul Anand]

-----Original Message-----



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

Right Daniel, it is PascalCasing. Thanks for correction.

 

[Daniel O'Connell [C# MVP]]

Right Daniel, it is PascalCasing. Thanks for correction.

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

 

[Jon Skeet [C# MVP]]

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.

 

[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!

 

[Bruno Jouhier [MVP]]

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.

 

[Sharon]

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.

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

 

[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!

 

[Jon Skeet [C# MVP]]

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

 

[Sharon]

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!]

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!