How to avoid property recursion

Solution 1:

Best way is to use "Auto implemented properties" here.

public int Test { get; set; }

If not possible to use "Auto implemented properties" for some reason use _ prefix(I don't prefer though).

If you also don't prefer to use some prefixes, then you have other option. You don't have to write the property code by hand. Let the IDE do it for you; that way you can avoid careless mistakes. (I don't know how I missed this in original answer)

Just type

private int test;

Select the field, Right click Refactor->Encapsulate Field. IDE will generate property snippet for you as below.

public int Test
{
    get { return test; }
    set { test = value; }
}

You don't need to bother clicking the context menu. If you prefer keyboard, shortcut is Ctrl + R + E.

Or get a Resharper, It will point your silly mistake immediately.

Solution 2:

Integration tests all passed

Then they weren't exhaustive enough tests. If there's an error that wasn't discovered by the tests, then you've got another test to write.

That's really the only automated solution here. The compiler isn't going to complain, because the code is structurally and syntactically correct. It's just not logically correct at runtime.

You can define naming standards, even use tools like StyleCop to attempt to enforce those standards. That would probably allow you to cover a lot, though it's not an ironclad solution and errors can still get through. Personally I agree with you that decorating variable names is unsightly in the code. Perhaps in some cases it's a valid tradeoff?

Ultimately, automated tests are your defense against these kinds of errors. At its simplest, if an error gets through your tests and into production then the response should be:

1. Write a test to reproduce the error.
2. Fix the error.
3. Use the test to validate the fix.

Granted, that only covers that one case, not every property definition in your code. But if this is happening a lot then you may have a personnel problem and not a technical problem. Somebody on the team is, well, sloppy. The solution to that problem may not be a technical one.

Solution 3:

Use code snippets.

For every property backed by a private field, use a custom code snippet you have created, instead of writing it up from scratch or letting IntelliSense do the job (poorly).

After all, this problem is about conventions and discipline, rather than language design. The case sensitive nature of C# and the subperfect code completion in Visual Studio are the reason we make these mistakes, not our lack of knowledge and design.

You best bet here is to eliminate the chance of accidents and having a predefined way of writing these repetitive things correctly is the best way to go. It also is much more automated compared to remembering conventions and enforcing them by hand.

There is a default code snippet in Visual Studio for this. Type propfull and hit Tab, then specify the instance variable name and the property name and you're good to go.

Solution 4:

In some cases you cannot get around setters and getters. But maybe you don't need the setters and getters if you follow the Tell, Don't Ask principle? It basically says to prefer having the object that has the data do the work, not some other object query a lot from the data object, make decisions, and then write data back to the data object. See http://martinfowler.com/bliki/TellDontAsk.html

Solution 5:

Could you not just write a test to cover this?

int constructorValue = 4;
TestClass test = new TestClass(constructorValue);
Assert.Equals(test.Test, constructorValue);

You may not want to write tests immediately to cover yourself from future wobbles, but you've found a bug, why not protect yourself from it again?

For the record, if I need a private field to store the value for a pulic getter/setter, I always underscore it. There's just something an underscore that screams privacy!

public string Test
{
    get { return _test; }
    set { _test = value; }
}

private string _test;