Why use public variables?

Question

Variables, methods and classes can receive various security levels. From my C# experience, there is:

public
internal
protected
protected internal
private

Now, I understand the use of making methods and classes private, or internal or protected, but what about variables? Even if I make a variable private, I can use a Property to call it from a different class.

I've always been thought that Properties are best-practice. So if I can use that, I don't need to call variables directly via an Instance.

Is there any reason not to make a variable private?

EDIT: I see some people talking about Properties as if they are nothing more than Glorified public variables

Quick reminder: public variables return just their value. With properties, you can do more. For instance:

public int AmountOfBooks{
  get {
    //code to check certain conditions
    //maybe trigger an event while we're at it.
    //and a few conditionals.
    return this.amountOfBooks;
  }

  set {
    //a few conditionals
    //maybe trigger an event
    this.amountOfBooks = value;
    //and I can do even more... I think, never tried this.
  }
}

Those of you who've read my profile know I'm a student. Using properties as "glorified public variables" is something I see a lot of fellow students do. The most common response when telling them they can do this is: "Is that allowed?"

Answer 1

Sure, there are situations in which it makes sense to have a public field. For example, if you are creating a struct solely for interoperability with an existing unmanaged win32 API.

But if you are building a regular managed object model, the best practice is to model the properties of your objects as properties, and use fields as the mechanism that privately implements the publically exposed functionality.

UPDATE: I'll take this opportunity to note that we have tried to make it very easy in C# 3.0 to write a property which simply accesses a backing store:

public int Foo { get; set; }

is exactly the same as

private int _Foo;
public int Foo { get { return _Foo; } set { _Foo = value; } }

but a lot shorter and easier to read. And of course if you need to expand it into the long form with a backing store later, doing so is not a breaking change.

You can also do this:

public int Foo { get; private set; }

if you want to make a property that is read-only to code outside the class/struct.

Answer 2

Properties are a best practice if there is any code you need to execute when the variable is set or gotten -- or if there is any incompatible-change in API involved should you ever need to add such code in the future.

Due to the latter clause, it most likely does make sense to use accessors "preemptively" in language that would otherwise require such incompatible changes (the best known example being the getThis/setThis convention in Java)!

But when your language lets you switch from public variables to properties and vice-versa without any incompatible change in the API (such as C#, Ruby, Python, ...), it's silly to carry around total boilerplate when the public accessors (getter and setter) do nothing except copying to and from a private variable -- even if you're certain your compiler can optimize them away, such boilerplate accessors just bloat the source uselessly, and waste an important design feature that's part of what makes such languages nice ones;-)