camelCase

[Peter Morris]

Okay, this is a vent. Probably the majority of people are going to disagree
with me, but I don't care!

When naming private fields the C# guidelines say to use camel casing


public class SomeObject
{
private SomeOtherObject reference;
}

The problem with this is that if you later wish to convert this to a
property you need to replace all uses of the camelCase identifier and
replace them with PascalCase. Now yes, you can use a refactoring tool, but
really, why?

For protected / public fields you need to use PascalCase because you might
not have access to the code that you need to change should you wish to
convert to a property. This means that when you look at

Name = "Pete";
You are looking at a property or a protected / public field.

name = "Pete";
You are looking at a private field, or a parameter, or a local variable.

if setting it from a constructor I need
this.name = name;


Whereas if you use PascalCase from the start converting to a property looks
like this:

public class SomeObject
{
private SomeOtherObject Reference;
}

becomes this

public class SomeObject
{
private SomeOtherObject reference;
private SomeOtherObject Reference
{
get { return reference; }
set { reference = value; }
}
}

I don't have to change any other code anywhere else at all. When I do a
diff in my version control I see a small area of isloated change rather than
changes scattered all over my class wherever I had to change camelCase to
PascalCase as in the original example (less noise in the diff).

In addition to this when I look at the code

Name = "Pete";
I can tell that this is not a parameter or a local variable. I don't need
to know if it is a field or a property, this is a good thing because only
the owner of the field should use the camelCase field anyway seeing as you
can't make the field private to the property (auto-properties go some way
towards solving this problem).

In a constructor I don't need "this" either
Name = name;

I see many reasons why private fields should be PascalCase, and yet I am
unaware of any advantages of it being camelCased.

In my opinion MS made an error of judgement when defining this specific
standard!

 

[Jeroen Mostert]

Okay, this is a vent. Probably the majority of people are going to
disagree with me, but I don't care!

When naming private fields the C# guidelines say to use camel casing


public class SomeObject
{
private SomeOtherObject reference;
}

Fortunately, private members are private, so no compiler or client will care
how you name them. In some circles, the old "m_member" construct is still
popular.

The problem with this is that if you later wish to convert this to a
property you need to replace all uses of the camelCase identifier and
replace them with PascalCase. Now yes, you can use a refactoring tool,
but really, why?

If the property is still private, why on earth would you need to replace
anything? If instead you're exposing the field as a new, public property,
this property would be PascalCase while your field is still camelCase, so
again, why replace anything?

Your internal code should continue referring to the private field, not the
property. Using properties from within a class is highly unintuitive (since
you're hiding implementation *from the implementation*) and can easily lead
to mistakes. If you find you need to abstract things like that, it often
pays to consider if you can split off the functionality to a new class. If
it's not big enough for that, use explicit private/protected getter/setter
methods instead. Again, for clients it's a different matter, they can
"enjoy" properties without knowing how you handle things internally, but the
internal code can't.

For protected / public fields you need to use PascalCase because you
might not have access to the code that you need to change should you
wish to convert to a property.

Yes. You need to use PascalCase for all client-accessible members,
regardless of type.

This means that when you look at

Name = "Pete";
You are looking at a property or a protected / public field.

No, just the latter.

name = "Pete";
You are looking at a private field, or a parameter, or a local variable.

if setting it from a constructor I need
this.name = name;

Still par for the course.

Whereas if you use PascalCase from the start converting to a property
looks like this:

public class SomeObject
{
private SomeOtherObject Reference;
}

becomes this

public class SomeObject
{
private SomeOtherObject reference;
private SomeOtherObject Reference
{
get { return reference; }
set { reference = value; }
}
}

If you like this better, then just use it. Personally, I don't -- I have
more than once been bitten by code (not my own) that used properties that
*didn't work*, because they relied on internal state that wasn't valid at
the time the property was accessed. Having the implementation behave as if
it's a client can be tricky.

In my opinion MS made an error of judgement when defining this specific
standard!

Then ignore it. It's a guideline, not a standard. The only people who'll
actually be affected functionally are the ones using reflection, and you
don't have to cater to those.

For the rest, anything you can get your co-workers to agree on (if you have
any) is fair game.

 

[Charles Calvert]

Okay, this is a vent. Probably the majority of people are going to disagree
with me, but I don't care!

When naming private fields the C# guidelines say to use camel casing


public class SomeObject
{
private SomeOtherObject reference;
}

The problem with this is that if you later wish to convert this to a
property you need to replace all uses of the camelCase identifier and
replace them with PascalCase.

All of what uses? Only the class SomeObject has access to reference,
so the changes will only be in that class. Do you mean that you would
change internal uses so that they use the property instead of the
field?

Now yes, you can use a refactoring tool, but really, why?

For protected / public fields you need to use PascalCase because you might
not have access to the code that you need to change should you wish to
convert to a property.

I avoid this by simply not making fields protected or public unless
they are also readonly (and usually static as well). The only
exception is controls on forms, which I will make protected as needed
to allow manipulation by derived forms.

[snip rest]

 

[Charles Calvert]

Fortunately, private members are private, so no compiler or client will care
how you name them. In some circles, the old "m_member" construct is still
popular.

If the property is still private, why on earth would you need to replace
anything? If instead you're exposing the field as a new, public property,
this property would be PascalCase while your field is still camelCase, so
again, why replace anything?

Your internal code should continue referring to the private field, not the
property. Using properties from within a class is highly unintuitive (since
you're hiding implementation *from the implementation*)

I'd disagree in cases where the setter is performing validation, as
it's a nice way to centralize that code.

and can easily lead to mistakes.

Further down you mentioned being bitten by assumptions about state in
a property, but I'd say that such problems are usually due to poor
implementation and can bite you just as easily outside of properties.

If you find you need to abstract things like that, it often pays to
consider if you can split off the functionality to a new class. If
it's not big enough for that, use explicit private/protected
getter/setter methods instead.

What is the advantage of internal accessors? You'd just call them
from the property (to avoid duplicating the code), which adds an
unnecessary function call. Anything that can be done in an accessor
can be done in a property, with the exception of returning error
codes. Unless you need error codes, this seems like an unnecessary
proxy.

[snip rest]

 

[Jeroen Mostert]

[introducing properties]

Your internal code should continue referring to the private field, not the
property. Using properties from within a class is highly unintuitive (since
you're hiding implementation *from the implementation*)

I'd disagree in cases where the setter is performing validation, as
it's a nice way to centralize that code.

I'd still make it a method so I can see it's doing more than just setting a
field. However, validation is a benign enough case that it can get a pass
(more below), but even then it better be restricted to validating just the
property you're setting, not, for example, validating it in the context of
other properties.

Further down you mentioned being bitten by assumptions about state in
a property, but I'd say that such problems are usually due to poor
implementation and can bite you just as easily outside of properties.

No, not "just as easily". If everything that looks like a field assignment
could be a property assignment, things get more complicated.

Again, this is less of a problem to clients, because there the issue's
inverted -- every assignment is a property assignment, or simpler (if
someone was shortsighted enough to use a public field directly). The client
doesn't have to worry about intermediate state, since there isn't any (from
the clients POV).

What is the advantage of internal accessors? You'd just call them
from the property (to avoid duplicating the code), which adds an
unnecessary function call.

There's no such thing as an unnecessary function call, unless the function
does nothing. Of course any function call could be expanded inline, but that
doesn't make the call unnecessary.

The advantage of an internal setter (an internal getter isn't half as
useful) is that it spells out HERE BE SIDE EFFECTS. If none of your
properties ever do more than eventually set a single field (such as in the
case of validation as you mentioned earlier) there's not much need for it. If.

Anything that can be done in an accessor can be done in a property

[snip]

Which is exactly the problem. Setting a field is guaranteed to have no other
side effects than changing the field.

All this is no problem if you're the sole author of the class, but as 80% of
my job is maintenance work, let's just say I've developed a healthy distaste
of private properties with magical side effects. I like my magic up front
where I can have a good look at it.

 

[Peter Morris]

All of what uses? Only the class SomeObject has access to reference,

so the changes will only be in that class. Do you mean that you would
change internal uses so that they use the property instead of the
field?

I mean that everywhere within the same class I do this

if (reference != null)

I would have to change to this

if (Reference != null)

I realise I can refactor it, but what benefit does this camelCase give? It
seems that it's one rule for everything but another for private. If I use
PascalCase for private fields too I only need to alter the code immediately
where the member is defined. When I do a diff in my source control I see a
few lines of altered code all in one place, not scattered all over the
place.

Sure it's not a BIG deal, but I fail to see the benefit.

 

[Peter Morris]

Your internal code should continue referring to the private field, not the

property.

I absolutely disagree. The whole point of a property is to give controlled
access to the field. If I were to keep direct access to the private field I
wouldn't be able to implement lazy instantiation for example.

If you have a property then I find it very rare that I should access the
private field directly outside of the getter/setter. In fact, I am
struggling to recall a time when I have ever done this.

Using properties from within a class is highly unintuitive (since you're
hiding implementation *from the implementation*)

Sure. Lazy instantiation cannot be done without making the member a
property. That's the whole point, the getter/setter are mini pockets of
functionality. Just because the class can bypass this logic doesn't mean it
should, in fact I would argue the opposite, it shouldn't.

 

[Michael B. Trausch]

Okay, this is a vent. Probably the majority of people are going to
disagree with me, but I don't care!

When naming private fields the C# guidelines say to use camel casing

public class SomeObject
{
private SomeOtherObject reference;
}

The way that I do it is to have private instance fields named like
"mVariableName" and private static fields named like "sVariableName".
I think that this makes things more clear when looking at the code.
Public static fields can be named "sVariableName" if desired, though I
named them "psVariableName" for additional clarity.

The problem with this is that if you later wish to convert this to a
property you need to replace all uses of the camelCase identifier and
replace them with PascalCase. Now yes, you can use a refactoring
tool, but really, why?

When I want to expose a private variable publicly, I use a property.

Then, the property is named like the private instance variable, but
without the "m" prefix that I mentioned above.

For protected / public fields you need to use PascalCase because you
might not have access to the code that you need to change should you
wish to convert to a property. This means that when you look at

Name = "Pete";
You are looking at a property or a protected / public field.

name = "Pete";
You are looking at a private field, or a parameter, or a local
variable.

if setting it from a constructor I need
this.name = name;

I treat protected fields in a similar fashion to private ones; that is,
I use the "m" prefix for them. Whether they are protected or private
for most circumstances is really irrelevant to the situation, and
reading the context to determine if it is a private field defined
locally or a protected field defined in a base class is easy enough to
avoid confusion, if the classes are designed well.

Like with any other language environment, you can use whatever code
style guidelines you choose. If you're working within the context of
another project, then use their CSG; if you're working on your own
project, then use whatever seems to be natural for you. As long as
it's well-defined and consistent, any competent programmer will be able
to read your code.

--- Mike

 

[Jeroen Mostert]

I absolutely disagree. The whole point of a property is to give
controlled access to the field. If I were to keep direct access to the
private field I wouldn't be able to implement lazy instantiation for
example.

Well, I detest lazy instantiation within a class. So there. My private pet
peeve.

The ability to leave the moment of instantiation of part of your class an
open question is undeniably powerful. This power comes at a price of
limiting your ability to reason about the class ("is it safe to load here?
how about here? will people mind that there'll be a 5 second delay here? or
here? what if it throws an exception here?") I rarely find the trade-off
worthwhile. Caching mechanisms that are external to the class (weak
references and such) are much more controllable.

If you have a property then I find it very rare that I should access the
private field directly outside of the getter/setter. In fact, I am
struggling to recall a time when I have ever done this.

You're looking at it the wrong way. The point is not to enable direct access
as if this brings some benefit over using properties, the point is to rule
out surprises.

Sure. Lazy instantiation cannot be done without making the member a
property. That's the whole point, the getter/setter are mini pockets of
functionality. Just because the class can bypass this logic doesn't
mean it should, in fact I would argue the opposite, it shouldn't.

I'm not saying it should bypass logic, if you want to introduce logic. I'm
saying that logic is usually better placed in a method.

Gee, this is somewhat funny -- you expected people to disagree with *your*
original point, but I end up having to defend mine from multiple angles.

 

[Peter Morris]

Well, I detest lazy instantiation within a class. So there. My private pet

peeve.

One example I have of this is a task which has a state machine, dictating
the steps of a wizard the user is executing. The flow of the wizard can
alter depending on different choises along the way. At any point the user
is required to input information the UI layer is presented with a view
object to display a control for. Are you saying you would create all of
these objects at the start of the process? This is a PPC application, and
some of those view objects contain a lot of data, you are going to run out
of memory pretty quickly, especially when the user is also 4 or 5 tasks
deep.

You're looking at it the wrong way. The point is not to enable direct
access as if this brings some benefit over using properties, the point is
to rule out surprises.

Well, I must say, I have never been surprised by my properties

 

[Jeroen Mostert]

One example I have of this is a task which has a state machine,
dictating the steps of a wizard the user is executing. The flow of the
wizard can alter depending on different choises along the way. At any
point the user is required to input information the UI layer is
presented with a view object to display a control for. Are you saying
you would create all of these objects at the start of the process?

No. Are you saying you're going to create (lazily initialized) properties
for all of them?

I'd group the controls belonging to tasks in separate instances and create
those on the fly, but not as a response to some code accessing a property if
I can avoid it.

Well, I must say, I have never been surprised by my properties

Neither have I! The problem is, I much more often deal with other people's
properties...

 

[Peter Morris]

I'd group the controls belonging to tasks in separate instances and create

those on the fly, but not as a response to some code accessing a property
if I can avoid it.

These aren't controls. They are view data. Another layer uses a factory to
create the control dynamically based on which view data type is active. So,
how would you create these view data objects?

 

[Jeroen Mostert]

These aren't controls. They are view data. Another layer uses a
factory to create the control dynamically based on which view data type
is active. So, how would you create these view data objects?

I know this one -- it's something with the "new" keyword, isn't it?

Look, I'm not out to discredit a design I have only the barest impression of
-- if lazily instantiated objects behind properties work for you, great. (We
are still talking about properties, right?)

 

[Peter Morris]

I don't think you are trying to discredit my approach, nor would I care if
you were

It's just that I gave an example of when lazy creation is needed and you
seemed to suggest you would do it differently and I am curious in case you
tell me something I like.

private SomeViewObject blah;
private SomeViewObject Blah
{
set { blah = value; }
get
{
if (blah == null)
blah = new SomeObject(); //Expensive on memory
return blah;
}
}

 

[Jeroen Mostert]

I don't think you are trying to discredit my approach, nor would I care
if you were

It's just that I gave an example of when lazy creation is needed and you
seemed to suggest you would do it differently and I am curious in case
you tell me something I like.

private SomeViewObject blah;
private SomeViewObject Blah
{
set { blah = value; }
get
{
if (blah == null)
blah = new SomeObject(); //Expensive on memory
return blah;
}
}

Looks fine, as long as:

- You just allocate memory for it, instead of something wonderful like
reading it from disk on-the-fly (thus creating a property whose access can
fail at absolutely any time);

- You don't care that the object will live for as long as its containing
object does, unless you resort to interesting code like

Blah.Foo(); // Bam, create on the fly
Blah = null; // But I don't want it any more
..
Blah.Foo(); // Bam, create on the fly

which is a good way of making sure NullReferenceExceptions never happen, but
an unintuitive way of controlling memory usage;

- You never, ever mistype "blah" for "Blah" and introduce an extremely
subtle bug (compare with mistyping "blah" for "getCreateBlah").

But note that I'm biased, and most of these drawbacks are minor. It's just
that I've had too many acrimonious debugging sessions with code that looked
like this:

private string setting {
get {
string value =
doSomeCalculationsAndMaybeThrowSomeExceptions(externalSource);
return value;
}
}

Reasoning about code that's full of properties like this makes them lose
their charm quickly. Looking closer, you can see that there are two things
that are especially harmful: the property is named as all private members
are named (with a lowercase letter) so it's indistinguishable from a field,
and the property's value is not necessarily stable (and even when it is,
it's not necessarily always accessible). Your lazy allocation property
manages to at least avoid both of these.

 

[Arne Vajhøj]

Okay, this is a vent. Probably the majority of people are going to
disagree with me, but I don't care!

When naming private fields the C# guidelines say to use camel casing


public class SomeObject
{
private SomeOtherObject reference;
}

The problem with this is that if you later wish to convert this to a
property you need to replace all uses of the camelCase identifier and
replace them with PascalCase. Now yes, you can use a refactoring tool,
but really, why?

Whereas if you use PascalCase from the start converting to a property
looks like this:

public class SomeObject
{
private SomeOtherObject Reference;
}

becomes this

public class SomeObject
{
private SomeOtherObject reference;
private SomeOtherObject Reference
{
get { return reference; }
set { reference = value; }
}
}

I don't have to change any other code anywhere else at all.

The other code need to be recompiled anyway, so it is a breaking
change anyway.

In addition to this when I look at the code

Name = "Pete";
I can tell that this is not a parameter or a local variable. I don't
need to know if it is a field or a property, this is a good thing
because only the owner of the field should use the camelCase field
anyway seeing as you can't make the field private to the property
(auto-properties go some way towards solving this problem).

I disagree.

I think the user of your classes deserve to know whether it is
a field or a property.

A property is syntactic sugar around a method call and they
need to know that it is not a simple assignment.

Arne

 

[Charles Calvert]

[introducing properties]

Your internal code should continue referring to the private field, not the
property. Using properties from within a class is highly unintuitive (since
you're hiding implementation *from the implementation*)

I'd disagree in cases where the setter is performing validation, as
it's a nice way to centralize that code.

I'd still make it a method so I can see it's doing more than just setting a
field.

Whereas I consider the property syntax an advantage. Given that I
don't generally expose member variables, if I see a public "field" on
a class, I assume that it is a property and thus might perform
validation.

The only downside of doing validation via a property is that one is
restricted to throwing exceptions in case of error, rather than
returning an error code. How much of a downside this is depends on
the architecture of the application.

However, validation is a benign enough case that it can get a pass
(more below), but even then it better be restricted to validating just the
property you're setting, not, for example, validating it in the context of
other properties.

Why? There are certainly times when a particular bit of state must be
validated in the context of the instance's overall state. Why is
doing this via an implicit setter (i.e. a property) worse than doing
it via an explicit setter?

No, not "just as easily". If everything that looks like a field assignment
could be a property assignment, things get more complicated.

I'm not sure that I agree that it's more complex. Why do you think it
is?

Again, this is less of a problem to clients, because there the issue's
inverted -- every assignment is a property assignment, or simpler (if
someone was shortsighted enough to use a public field directly). The client
doesn't have to worry about intermediate state, since there isn't any (from
the clients POV).


There's no such thing as an unnecessary function call, unless the function
does nothing.

Of course there is. Every function call has a cost, so adding
additional function calls when they're not necessary is a waste. Note
that I consider good organization of code necessary, so I'm not
advocating huge functions here.

I just don't see the point of using an explicit, internal accessor if
the interface already contains a property. Why not use the property.
It's not "hiding" the implementation from the class any more than an
accessor is.

[snip]

The advantage of an internal setter (an internal getter isn't half as
useful) is that it spells out HERE BE SIDE EFFECTS.

I think that this is only true if you think it's true. You seem to
think that properties don't indicate side effects, or at least don't
indicate them as strongly as functions. I infer from what you've said
that this is because one might have difficulty distinguishing between
properties and member variables. Is that correct?

Anything that can be done in an accessor can be done in a property

[snip]

Which is exactly the problem. Setting a field is guaranteed to have no other
side effects than changing the field.

All this is no problem if you're the sole author of the class, but as 80% of
my job is maintenance work, let's just say I've developed a healthy distaste
of private properties with magical side effects. I like my magic up front
where I can have a good look at it.

Having done quite a lot of maintenance work myself (and some of it on
some really crappy code), I've drawn different conclusions.

Of course, some of my conclusions may result from the way that I
approach the organization of the code:

1. Everything is private unless there's a need for it to be protected
or public.

2. Instance variables are private, unless they are controls marked
protected so that derived forms can access them for data input/output
and layout.

3. Instance variables all start with "m_" (You can take the programmer
out of MFC ...)

4. Any instance variable that needs to be exposed via the interface is
exposed via a property.

5. Property names start with an upper case letter, which distinguishes
them internally from instance variables.

6. Class variables may be public if static and (almost always)
read-only. The default is still private.

 

[Charles Calvert]

I mean that everywhere within the same class I do this

if (reference != null)

I would have to change to this

if (Reference != null)

I realise I can refactor it, but what benefit does this camelCase give?

I think that the intended benefit is differentiation between private
instance variables and [protected|public instance variables,
properties].

Personally, I prefer:

private object m_obj = new Object();
protected Combobox m_comboStatus; // available to derived forms

public object Obj
{
get { return m_obj; }
set { m_obj = value; }
}

This way, if you use "m_obj", you know it's the instance variable,
whereas "Obj" is the property.

This doesn't eliminate the refactoring issue that you raised, but it
does eliminate the conflation of instance variables with properties
based on the name.

[snip]

 

[Jeroen Mostert]

[introducing properties]
Your internal code should continue referring to the private field, not the
property. Using properties from within a class is highly unintuitive (since
you're hiding implementation *from the implementation*)
I'd disagree in cases where the setter is performing validation, as
it's a nice way to centralize that code.

I'd still make it a method so I can see it's doing more than just setting a
field.

Whereas I consider the property syntax an advantage. Given that I
don't generally expose member variables, if I see a public "field" on
a class, I assume that it is a property and thus might perform
validation.

This makes sense if property names are always capitalized, regardless of
accessibility level, but this conflicts with other guidelines, and I've
certainly not seen this applied consistently.

Why? There are certainly times when a particular bit of state must be
validated in the context of the instance's overall state. Why is
doing this via an implicit setter (i.e. a property) worse than doing
it via an explicit setter?

Are these two pieces of code equivalent?

field1 = "one";
field2 = "two";

and

field2 = "two";
field1 = "one";

? If they are fields, then obviously, without any question. If they are
method invocations, then I equally obviously don't know; I have to know what
the methods do first. If they are properties, I have to recognize them as
such before I can say what's the case, but assuming they're fields would be bad.

I'm not sure that I agree that it's more complex. Why do you think it
is?

See above.

Of course there is. Every function call has a cost, so adding
additional function calls when they're not necessary is a waste. Note
that I consider good organization of code necessary, so I'm not
advocating huge functions here.

I think we're talking cross-purposes. What I was trying to get at was that I
don't consider them unnecessary, while you do. That's the difference we're
talking about. Your argument that "it adds an unnecessary function call" is
no argument; the argument you're making is that setters are unnecessary. My
argument was that, being impossible to confuse with field assignments, they
can have some small added value. The overhead of a (non-virtual) function
call is negligible, so just about anything with non-zero value can justify
an extra function call.

I just don't see the point of using an explicit, internal accessor if
the interface already contains a property. Why not use the property.
It's not "hiding" the implementation from the class any more than an
accessor is.

Not on a semantic level, no. I'm strictly talking syntax.

[snip]

The advantage of an internal setter (an internal getter isn't half as
useful) is that it spells out HERE BE SIDE EFFECTS.

I think that this is only true if you think it's true. You seem to
think that properties don't indicate side effects, or at least don't
indicate them as strongly as functions. I infer from what you've said
that this is because one might have difficulty distinguishing between
properties and member variables. Is that correct?

Yes. Again, if you make sure that properties cannot be confused with fields
within the class (by having no private properties, or by capitalizing or
otherwise conspicuously naming private properties) there is less of an
argument...

5. Property names start with an upper case letter, which distinguishes
them internally from instance variables.

....which you seem to say here, although I can't determine if that would
include private properties for you.

 

[Jeroen Mostert]

Are these two pieces of code equivalent?

field1 = "one";
field2 = "two";

and

field2 = "two";
field1 = "one";

? If they are fields, then obviously, without any question.

Well, one very small footnote to this: not if we have to factor in
multithreading. But let's not go there...