Reviewed some Unity game code yesterday

[HideInInspector] public NavMeshAgent agent;

Me:”why is this hidden if it’s public”
Dev: “so designers don’t fuck it up”
Me: “then why have it public”
Dev: “I need it to be set by another class”
Me: “then make it a private bar and create a get:set function”
Dev: “Why?”
Me: “Because hiding a public variables from designers is a bad model and by standards things now to be shown to the inspector should be private”

This shit is why I have no confidence in devs my age

Um... I do this all the time. Had no idea it was bad practice.

@qdsp13 if you’re using C# specifically it is. I would looking into getters and setters in C# if you need private variables accessed by other files. But with games you want it to be as modular and independent as possible. One object dies you don’t want the game crashing.

During development its not bad to do so if you have to toggle it on and while building it.

I honestly do not see the point of getters and setters, if all they do is just a simple return and assignment, respectively, and they are named exactly like the variable.

If they do something else, like check for invalid values, alright, do it, but if they don't, there is no point in adding a function call for absolutely nothing (which could be inlined, but it is not guaranteed).

Encapsulation is okey, but those simple getters setters do not encapsulate, because they behave exactly like an assignment.

Public variables exist for a reason, and the general consensus among Java/C# that all member variables should be private with public accessors makes no fucking sense.

@aritzh thanks. This is appreciated

@aritzh

It makes sense because many frameworks requires it to function properly.

Serialization works with properties not fields. WPF binding works with properties not fields. These are the two examples that comes to me but must hwve a lot of others.

lol i code Unity in js

@Etnath I see those frameworks as having a bad design, just like using simple accessors.

@Aiei Well you're stuck in the older versions then, because in recent updates they removed js support

@qdsp13 yup my team still stuck with v5 because of old project. we have to wait for a new ip to finally get to use c#. cant wait tho.