More on properties vs fields


Some nice comments on what I wrote.


First, a non-controversial question. Robin asked whether you would capitalize them in that case, and I think you should, as having something accessed externally that isn't properly cased will be surprising to people.


Dani - and others - have pointed out that properties leave your options open in case the software is used in ways that make the property more useful. This is certainly true, and I think it comes down to how you value that flexibility over the tax that you're paying to have properties. I would usually rate the simplicity higher, but it does depend on what you're writing, how likely the code is to get repurposed, and how likely it is that a property would ever be needed. I find as I get older I'm valuing simplicity more.


Finally, Kristof points out that a field can be passed as an out or ref parameter while a property cannot, which means that adding a property to code can break the client code. This is a good point. I do think, however, that I'd want my code to break in that situation - if something is a property I should do some thinking about whether it's a good idea to be passing it as an out or ref (the same reason C# doesn't write helper code to make this work by default).


Kristof's comment reminded me one more reason to use properties - some of the BCL infrastructure works with properties but not with fields.


 

Comments (6)

  1. josh j says:

    Hey Eric,

    Great commentary - appreciate the commentary.  It's good to read your opinion - thought provoking.

    -j^2

  2. steve@stevecooper.org says:

    I'm still uncertain of the real reason why we have fields at all; apart from the ref/out distinction, it seems to me that it's always preferable to have a trivial field implementation. Given the immense amount of code you need to write, why isn't it better to use the field syntax { string foo = ""; } to generate a trivial property? Can't the JIT deal with performance here?

  3. dd says:

    sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

  4. dd says:

    sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

  5. Thomas Eyde says:

    Of all the fuss around public fields and properties, I find three things that stands out:

    1. The trivial property is too verbose.

    2. A property can't be passed as an out/ref parameter.

    3. A field is not data bindable.

    Regarding the trivial property and verbosity, didn't the language designers see the problem? Or discovered it early on?

    I don't mind the restriction on properties and out/ref parameter. I think of out/ref parameters as a code smell, and avoid them at all cost.

    But why someone decided that public fields are not databindable is something I don't understand. What is it that I don't understand?

    And finally, when a property and a public field are so similar in usage, but yet so different, why didn't the language designers remove this ambiguity? If it looks like a property, why isn't it a property, period?

  6. JH says:

    You mention the "tax" of having the properties. What are the performance (and otherwise) implecations of implementing "dummy" properties versus the gain of being consistent with other areas in your code where you are implementing properties that aren't just simple getters/setters?

Skip to main content