Q:

Using Getters and Setters in Unity

I have another question about this with getters and setters. Now that I started working with c# getters and setters as I understood them. The problem I see is that why should I make public variable that looks like this:
// Variable
private int _iRandomNumber
// Getter and setter
public int iRandomNumber
{
     get { return _iRandomNumber; }
     set { _iRandomNumber = value; }

}

I don't see the point of that since what different would it then be to just make the variable public since it's anyway got the get and set in the same bracket?
However if I do like this:
// Variable
private int _iRandomNumber
// Getter and setter
public int GetiRandomNumber { get { return _iRandomNumber; } }
public int SetiRandomNumber { set { _iRandomNumber = value; } }

Then when I try to use my SetiRandomNumber by itself Unity complier complains that I cannot use my SetProperty since I do not have a GET property inside my SET. Should I really have to make it like the first example I wrote because as I wrote then what's the point of Getters and Setters in c#?
Or should I instead move away from them, like I asked from the beginning and make functions for each Get and Set like in c++ so I can actually use them by themself?
Sorry for making this a new question, however it was not possible to add this as a comment in my previous question since it was to long. 

A:

Properties allow you to fire events when values are set, for instance:
public string Name {
    get { return name; }
    set {
        name = value;
        var eh = NameChanged;   // avoid race condition.
        if (eh != null)
            eh(this, EventArgs.Empty);
    }
}
private string name;
public event EventHandler NameChanged;

An added bonus is that you can track when your property gets set or read by putting breakpoints in the getter/setter with your debugger or diagnostic print statements.

A:

I don't see the point of that since what different would it then be to just make the variable public since it's anyway got the get and set in the same bracket?

The difference is that you're separating your implementation detail (a field) from your API (the property). You could later change the implementation, e.g. to use one long variable to serve two int fields. (That's just one random example.) Or you can provide validation and change notification in the setter. Or you can perform lazy computation in the getter. Or you can make the property read-only from the outside, but writable privately. The list goes on.
Your second code declares two different properties - one read-only, and one write-only, both backed by the same variable. That's non-idiomatic C# to say the least, and gives no benefit. There's no linkage between those two properties, whereas in the first version there's a clear link between the getter and the setter as they're parts of the same property.
One thing to note is that your first example can be more concisely expressed with an automatically implemented property:
// Removed unconventional "i" prefix; this follows .NET naming conventions.
public int RandomNumber { get; set; }

That creates a private variable behind the scenes, and a public property whose getter and setter just use the private variable. Later if you want to change the implementation, you can do so without affecting the API.

