Is code cleanliness a good enough reason to use a property over a field?

I have a class that is Enumerated to allow subscripting of a list contained within it. For this reason, the List does not need to be publicly accessible through a field or property.

public class Foo : IEnumerable<Bar>
{
    private List<Bar> _positions;

If I have other properties in my class with private setters, future programmers will see PascalCase, PascalCase, PascalCase, _asdfghjk. Huh? What the hell was that? _asdfghjk sure does look pretty ugly.

Is the consistency created by making _positions into something like

private List<Bar> Positions { get; set; }

a good enough reason for using a property over a field?

Jon Skeet
people
quotationmark

I wouldn't introduce a fully-private property just for the sake of it. It can be useful to do so if it computes the property value from state, or performs validation etc - but don't just do it for the sake of it.

Personally I'd just call it positions instead of _positions - heck, you could call it Positions if you really wanted all the names to be consistent with each other (but inconsistent with normal naming conventions).

It shouldn't be a particularly rare thing to have a field which isn't exposed by a property - I'd be worried if seeing such a thing bothered a developer. Likewise not every property ought to be an automatically-implemented property, so developers should be used to seeing both foo and Foo as members of a class (with foo being private).

people

See more on this question at Stackoverflow