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!

506 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 →

    10 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...
      • Sven FabSven Fab commented  ·   ·  Flag as inappropriate

        I'm also opting for the general solution where we have the possibility to declare variables/fields that live in the instance but are visible only in the code block that declared them. The main aim here would be to clean up the (internal) class member list and remove ambiguity when accessing these members. Using the same syntax as for regular fields would allow to easily move them between class and member level as needed.

        public class Foo
        {
        public int AddLine()
        {
        private int linesAdded = 0; // scoped in class and execued on instantiation
        return ++linesAdded;
        }

        public string Name
        {
        private string _name; // scoped in class and execued on instantiation
        get { return (_name ?? (_name = this.GetName())); }
        set { _name = value; }
        }

        public static void MyFunction()
        {
        private static object myLock = new object(); // scoped in type and executed on type initialization
        lock(_myLock)
        DoSomeThreadSafeStuff();
        }
        }

      • Colin WadeColin Wade commented  ·   ·  Flag as inappropriate

        Remove the statement from your suggestion:

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

        As mentioned by Brandon Bonds, the real advantage of this is that the property becomes truly the master of the backing field, while still allowing the developer to implement special logic into get/set.

        The best we can do today is make private backing fields as members of the class. This mostly protects the underlying value by requiring external mutation to be performed through the property. This is not complete, however, as the field is still not protected from the rest of the class declaring it.

        There isn't really a downside to this that I can fathom.

      • 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