Question about clean code and public vs private variables

[mellow oriole]

Trying to ensure best practices and learn clean coding standards...

I know that public variables are generally bad, but sometimes you HAVE to manipulate veriables from elsewhere... So which is better:

1. A public variable

or...

2. A private variable with a public method to manipulate it?

or...

3. A third method that I am unaware of...

2 seems better (even though it's a tad more work) b/c at least I can have the method report who accessed it for troubleshooting purposes.

[severe pollen]

3. A method you seem unaware of:
   C# has a concept called "Properties".
   Those can be accessed like Fields, but behave like Methods. By using them, you spare yourself the hassle of declaring entire get/set methods, sometimes even of declaring the fields themselves.

For example: cs public float Foo { get; private set; }The above property can be read by every class, but only set from within the declaring class.
Under the hood, it will compile to a backing field and two methods, but you would still use it like someObject.Foo.

Note that getters and setters in properties can also have bodies; in that case, the value passed into the setter is accessed via the value keyword.
When a body is declared for the getter/setter, no backing field will be generated either. ```cs
private float foo;

public float Foo {
get {
return foo;
}
set {
foo = value;
}
}Or the shorter variant: cs
private float foo;

public float Foo {
get => foo;
set => foo = value;
}The bodies however do have the advantage, that you can process values before setting/getting them:cs
private float foo;

public float Foo {
get => foo;
set => foo = Mathf.Clamp(value, 0f, 10f);
}```

[mellow oriole]

Thank you much! Will play and figure that out. Appreciate the detailed push in the right direction!!

[severe pollen]

You're welcome!

[mellow oriole]

@severe pollen clarifiying question... is a method defined AFTER you've defined the foo variable, yes?

public float Foo { get; private set; }

So proper use would be:

private float foo;
public float Foo {get; private set;}

https://www.youtube.com/watch?v=qpbRrxaEzQE&t=1s

auto-properties (9:18 in the vid above)

[azure ermine]

If you want a private variable that you can edit within the editor you can also use
[SerializeField] private float cameraZoomLevel;
Or the opposide:
[NonSerialized] public Vector2 arrowMoveVector;
For when you need something to be accessing in another script but not visible in the editor

[severe pollen]

No.
That right there declares two individual members (foo and Foo), that don't have any connection or knowledge of each other.

[trim drift]

This is a good article on the subject

https://blog.oliverbooth.dev/2022/02/16/youre-exposing-state-badly/

[severe pollen]

Not sure what you mean by this.
If you're asking whether backing fields have to be declared before their properties: Technically no. I just like to keep it that way.

[mellow oriole]

I asked that before finding the vid I linked above. Thank you!

@trim drift great stuff, thanks for weighing in.

Current work is definitely scheduled for a complete refactor and I will be using properties (auto and non) when I do that. Cheers all!