[actf]

I really disagree that C# getters and setters are less readable than a public field. Compare:

   public string Field { get; set;}

to

   public string field;

I felt I had to reply to this comment to discourage this practice for a couple of reasons:

1) By convention anyone reading your code will think this is very strange, and it will force them to spend additional time reading your code to understand why you are breaking such a strong convention.

2) Using properties really will make your life easier when you need to track down a state change in your program. Detecting a state change on a public setter is a lot easier than detecting state change on a public field.

3) In C#, at least, using public fields where you should be using public properties will make creating an interface on existing code significantly more difficult - as interfaces can only define public properties, and not fields.

In short please don't do this. It's really bad practice just to save a couple extra characters, and if I inherit your code someday I'll probably want to strangle you.

[mbell]

1 + 2 are exactly why I do it. If your muddling around with the internal state of another object there should be alarm bells in your brain triggering you to think "should i really be doing this?"; It should look weird.

Hiding fields behind method calls obscures what your really doing. I like that syntax highlighting changing the color on field access and that there aren't parenthesis at the end of the call. This is what I meant by readability, I instantly know that I'm muddling around with the inner state of another object. Figuring out whats really going on with getter and setters is made far worse by the common practice of 'overloading' getters and setters to accept / return different types than the internal state representation.

3 - I would consider defining field getters in an interface poor form. There is a reason interfaces (in Java at least) do not allow field definitions. Defining a 'getter' in an interface is just circumventing that protection and a strong indication the code should be refactored in a different way.

[ajanuary]

Things consuming an object shouldn't care how it does what it asks, only that the object does it.

If knowing that something is a field rather than an opaque getter is important to the consumer, then the consumer knows too much.

You know you're messing with the state of an object when you do object.Something. That it's being messed with by a method call or a field is immaterial.

The syntax for consuming a field or a property are exactly the same. I don't see how fields ring alarm bells while properties don't.

[gjulianm]

In C#, properties are handled just like fields:

    class Foo {
       public string Bar { get; set; }
    }

    Foo.Bar = "test";

But I still don't get why wouldn't you use getters/setters or properties. For example, let's say you want to get the number of items in a list. How'd you do it without something like this

    public int Count { get; private set; }

?