Is it OK to use a public variable in C# if it is readonly?

Question

Is there some internal difference between the C# syntactic sugar way of making properties:

public string FirstName { get; set; }

and just making public variables like this:

public string LastName;

I assume the first way is preferred and the second to be avoided. However, I often see this type of readonly property being used which is a form of the second type above:

public readonly string InternalCode;

Is this a best-practice way to create readonly property?

using System;

namespace TestProps
{
    class Program
    {
        static void Main(string[] args)
        {
            Customer customer = new Customer();
            customer.FirstName = "Jim";
            customer.LastName = "Smith";
            customer.Show();
        }
    }

    class Customer
    {
        public string FirstName { get; set; } //prefered
        public string LastName; //avoid
        public readonly string InternalCode; //???

        public Customer()
        {
            InternalCode = "234729834723984";
        }

        public void Show()
        {
            Console.WriteLine("{0}, {1} ({2})", LastName, FirstName, InternalCode);
            Console.ReadLine();
        }
    }
}

Answer 1

Since he didn't answer (yet) and no one else referenced this yet: There is a great article on this topic by Jon Skeet amending his book C# in depth (give credits to Jon):

Why Properties Matter

Answer 2

Using a property provides an interface which is more resistant to change in the future. Let's say some time in the future, a decision is made to add a prefix to the internal code.

Using a public readonly variable exposes your internal structure and you will have a hard time adding the prefix to every line you used the internal variable of the class.

Using a Property, you can just write the following

public string InternalCode { 
    get { return _prefix + _internalCode; } 
}

and you're done!

Answer 3

In my opinion, it's ok to expose public fields (especially if they're readonly or const). Having said that, I'd say that in the example you're presenting, I'd probably go with properties since they'll give you 2 advantages (over fields): 1) better encapsulation and may let you adapt your code in the future and 2) if you're doing data binding, then you do need the properties.