Something I learned from Jason Storey not long ago is that anything that evaluates to evalue is interchangeable from that value - so in the case of this method all the code could be refactored in a single line like:
meshRenderer.enabled = UnitActionSystem.Instance.GetSelectedUnit() == unit;
It’s a small thing but, I think, very handy for shortening code while not sacrificing readability IMO.
Yup that works, as to whether that is more or less readable depends on a per person basis, depending on your level of experience with statements like that.
For me nowadays yup I would say that is easy to read. But if you had shown me that code 5 years ago I would have found it tricky to read.
I agree, readability is certainly subjective.
When tuples were first introduced in C#, I started using it instead of out parameters
// out parameter
public bool TryGetSomething(out Something something) { /* ... */ }
// tuples
public (bool success, Something something) TryGetSomething() { /* ... */ }
It wasn’t long before someone asked ‘How does that even compile?’ (The novelty has since worn off, and I’m back to out parameters in most cases)
Another one that stumped a few people was getting the neighbours of a cell, excluding diagonals
for (int z = -1; z <= 1; z++)
{
for (int x = -1; x <= 1; x++)
{
if (x == 0 && z == 0) continue;
if (x != 0 && z != 0) continue;
Debug.Log($"Found neighbour at x: {pos.x + x}, z: {pos.z + z}");
}
}
I was asked how the Debug.Log even runs, because it looks like those two if statements will prevent the code from ever getting there.
Sorry, I digress. While I usually write code the way @VladStoyanoff mentioned, I try to gauge my audience’s experience level - especially here on the forum. It is better to have someone understand the code than try to make it ‘short’. I don’t always succeed because years of coding has ingrained (good and bad) habits that I sometimes overlook