Is this a bad or good coding habit?

Unity Engine
, , ,
1

whenever I have methods that run every frame, for example

public int everyFrameMethod()
{
     int a = 0;

    return a;
}

instead of doing this I have been doing

public int a;
public int everyFrameMethod()
{
     a = 0;

    return a;
}

based on the notion that this will lead to less garbage collection since im never initiating a new int

now bear in mind that the example is super simplified, of course the most effective would be to just do return 0; ,

this is just a simplified example to ask about whether its a good coding practice or bad to avoid initiating variables within methods and instead use permanent fields within the class that never get collected

Your thoughts would be appreciated

1 Like
2

Bad in this example because integers are value types which live on the stack and don’t create garbage.

I recommend familiarising yourself a little more with reference and value types in C#.

5 Likes
3

Always benchmark, if you had benchmarked you would have noticed both does not alloc

1 Like
4

I agree with the above and will also like to add that micro optimizations like this are not needed during writing code, are needed only if eventually this actually causes a performance problem.

Having your variables local, is preferable because it reduces the number of states an object can have. Lesser states for an object or even better going functional and having immutable objects with only one possible state, greatly increases productivity because it minimizes the possible bugs and the time you need for testing and debugging.

Even if this was a reference type and was allocating, I would argue that during development it should still be local and if your benchmarks at production show you that it causes a problem because it is in a hot path or is the bottleneck and also this performance loss is greater than the performance of other operations, only then you change it to global to have it cached.

3 Likes
5

Food for thought: Good/Bad programming habits do not equate to “less garbage collection” or even speed of execution. Good programming habits should useful across, projects, computer languages and even time.

The optimization you are hoping for (as was explained above) doesn’t actually occur. Still doesn’t mean your example is necessarily a bad idea if other methods need to reference property “a”.

Local variables are a benefit… I’ve coded in a language that only support public variables. Talk about a nightmare.

1 Like
6

Methods that mutate members are code smell though. I mean that the mutation is a sideeffect.

Its much more maintaible to pass into the method and operate on the return value.
I tend to minimize the number of members and favour passing data

7

Not to put too fine a point on it but “yes” I agree and suggest recognizing and avoiding code smell. Not sure about generalizing methods though.

The example here was minimal and the purpose not entirely clear. :slight_smile:

2 Likes
8

This is arguable.

It’s certainly true if you are doing pure functional programming, but not if you’re doing object-oriented programming (because creating simple abstractions and encapsulating implementation details is more important than strict immutability) or data-oriented design (because optimizing for data transformations is more important than strict immutability).

But I do agree that it’s a good idea in general to:

  • Aim to keep the scope of variables as small as possible (local > private > public).
  • Avoid methods having any unexpected side effects.
  • Be wary of member variables, as they can quickly introduce a lot of cyclomatic complexity to your methods. Keep them to a manageable level, and encapsulate the complexity they bring behind simple abstractions.
2 Likes
9

Well for example dependencies are naturally members and data is naturally passed around.

There are always exceptions, but as a rule of thumb.

transform.rotation = GetSomeRotation();

VS

SetSomeRotation(transform)

I tend to favour the former

Edit: the latter can add functionality without name of the method changing, i have seen it done by team members at dayjob.

2 Likes
10

Oh good a conversation :slight_smile: Your example can actually serve as an opposite case. No question that if the rotation needed can be obtained via a method it serves it’s purpose.

On the other hand if it isn’t a matter of setting a rotation but doing “work” that can set a rotation as part of it’s job then calling a ReinitializeTarget() method (to make up a name) can reasonably modify the transform of the object as part of the reinitialization.

I suspect the ideal solution relies heavily upon the context.

1 Like