title: When does it make sense to use a public field?
body: <p>This is a question I have had for a while now:</p>
  
  <p>When does it make sense to expose a field publicly like so?</p>
  
  <pre><code>public class SomeClass()
  {
     public int backing;
  }
  </code></pre>
  
  <p>The downside of doing this (in addition to angering OOP elitists) is that you have to introduce a breaking change to your API if you ever need to add any logic on top of this data. I suppose that is what the elitists are on about.</p>
  
  <p>Best practice in Java and C# has long been to use getters/setters or properties to access fields.</p>
  
  <pre><code>public class SomeClass()
  {
     private int backing;
  
     public int getBacking()
     {
        return backing;
     }
  
     public void setBacking(int v)
     {
        backing = v;
     }
  }
  </code></pre>
  
  <p>C# has evolved this to pretty simple syntax with automatic properties:</p>
  
  <pre><code>public class SomeClass()
  {
     public int Backing { get; set; }
  }
  </code></pre>
  
  <p>Lazy me still feels this is too long though since it something I find myself doing a lot. More importantly, I am not sure I know where a public field would make more sense.</p>
  
  <p>Why not just treat publicly declared fields as properties (or methods) behind the scenes? That way it would be impossible to anger decoupling gods and be a bit less typing to boot.</p>
  
  <pre><code>public class SomeClass()
  {
     public int backing;   // The same as public int backing { get; set; }
  }
  </code></pre>
  
  <p>For a property that does nothing but wrap the underlying field, I am pretty sure the JIT optimizes the method calls away so performance is probably not the issue. Any thoughts? (other than the proper case convention for the field name)</p>
  
  <p><strong>EDIT:</strong> Thanks for all the responses. I feel like perhaps not everyone is understanding my question though. When would a public field be a better choice than a property? Why is it a better choice? If the only reason is convenience (less typing and clutter), then what would be the downside of having the compiler generate a property "under-the-hood" whenever a public field is encountered. Basically, it would be impossible to create a true public field (because they would all be properties). What would be wrong with that? Thanks.</p>