I suggest you ...

Feature Request: Local Fields within Properties

A simple property in C#:
int MyProperty
{
get
{
return _myProperty;
}
set
{
_myProperty = value;
}
}
private int _myProperty = 42;

Now, imagine the requirement appears that the code must be documented using the /// conventions.

/// <summary>MyProperty is wonderful...</summary>
int MyProperty
{
get
{
return _myProperty;
}
set
{
_myProperty = value;
}
}
/// <summary>I don't want to document this but I'll get a diagnostic if I don't.</summary>
private int _myProperty = 42;

It's too bad that
/// <summary>MyProperty is wonderful...</summary>
int MyProperty
{
int _myProperty = 42;
get
{
return _myProperty;
}
set
{
_myProperty = value;
}
}
is not supported.

I don't think this feature would involve any change to the CLR or byte code. It has the added advantage that the backing field (_myProperty) is bound to the property rather than being declared who knows where else in the solution.

Of course, the downside is that _myProperty is no longer available for other purposes because its scope is that of the property itself.

Another downside is that once C# allows one declaration within a property's body, somebody will want more. Maybe that can be solved by some kind of refactor tool that extracts a property and produces a complete class.

Feature Request #2: a refactor to class for properties ... JUST KIDDING! :)

Best!

500 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    WeBMartians (Bruce)WeBMartians (Bruce) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    7 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AndyAndy commented  ·   ·  Flag as inappropriate

        Instead of _myProperty I would suggest a constant key word like "field". Similar to the key word value:

        int MyProp
        {
        get { return field; }
        set { field = value; }
        }

        This would make refactoring much easier.

      • WeBMartians (Bruce)WeBMartians (Bruce) commented  ·   ·  Flag as inappropriate

        Wow! ...never imagined this would spark any interest...

        - My primary goal is just the reduction of code text (more text means more opportunities for bugs). Mark, while your technique does yield greater encapsulation, it requires some additional code.

        - i agree with Nathan that most environments do not require /// comments with private declarations. However, some <work> environments require, in the coding specifications, full commenting.

        Query: can some of this be accomplished through System.Component?
        [System.ComponentModel.DefaultValue(42)]
        public int DefaultValueInt { get; set; }

        This leads to the consideration of not just DefValue but MaxValue and MinValue as well as some non-(exception)throwing means to validate candidate values.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I agree with Brandon; I want to be able to protect the field from direct manipulation.

      • Brandon BondsBrandon Bonds commented  ·   ·  Flag as inappropriate

        The real advantage for this idea is additional encapsulation. Only the property is allowed to access the backing field.

        If I create a property with the intention that anyone who needs access to that data should go through the property, unfortunately years down the road perhaps I forget or perhaps another team member doesn't realize this intention. This suggestion fixes this problem.

        And really this is little different from how automatic properties work internally, except now you can add additional behaviors when needed such as firing PropertyChanged:

        public string MyData
        {
        string _myData = "default value";

        get { return _myData; }
        set
        {
        _myData = value;
        FirePropertyChanged("MyData");
        }
        }

      • Nathan Phillip BrinkNathan Phillip Brink commented  ·   ·  Flag as inappropriate

        My personal convention for disabling warnings about members that don’t need documentation is to just put “///” in the line before the member which C# complains about lacking documentation. It mutes the warning just for that member and, in my mind, marks the member as “not being worthy of documentation” or “intentionally not documented”. Great for struct constructors and backing store members. Except, I have never noticed the compiler warning about missing XML documentation on private members. They’re not part of the public interface and C# normally only warns avoid members which are exposed as an assembly’s API/accessible to other assemblies.

      Feedback and Knowledge Base