Re: camelCase

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Mon, 01 Dec 2008 19:55:14 +0100, Jeroen Mostert
<jmostert@xxxxxxxxx> wrote in
<49343313$0$189$e4fe514c@xxxxxxxxxxxxxx>:

Peter Morris wrote:
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*)

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]
--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
.

Relevant Pages

  • Structural question regarding scope of variables
    ... Private Fields ... Private Instance Methods ... different connection strings, based on where the data will need to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Assigning "this"
    ... Define a private inner-class to hold all of your private fields (I ... Suppose I have two functions called DoubleSizes() and Double. ...
    (microsoft.public.dotnet.languages.csharp)
  • private field and public property naming conventions
    ... Has anyone found any naming convention guidelines for private fields ... public string MyVariable ... Public Property MyVariable() As String ...
    (microsoft.public.dotnet.framework)
  • Re: Enabling Access to Private Fields
    ... They should still be private to everything ... > access private fields on classes in the assembly that's performing the ... > dynamic compilation. ...
    (microsoft.public.dotnet.security)
  • Re: Universal Healthcare Flops In Massachusetts
    ... In private health care, I have a choice of providers, so I don't have to ... qualified Doctor where I have control of my care. ... I prefer the private system. ...
    (soc.retirement)