The first thing you have to evaluate about this is understanding the software development process and how to write code. A code should express clearly and objectively what it is doing. Being short is a good feature, being too short, being weird, using tricks to look short is not a good feature.
That said, I see no problem in what you did originally, this code is simple and clear, expresses well what you should do, is organized and will facilitate maintenance in the future.
If you try to do something that runs away from that, it’s gonna be a weird code, and it could be trouble in the future. You may be starting out and not have that clear vision, I’ve been doing this for over 35 years, and I’ve tried to make everything as short as possible. Today I see the mistakes I’ve made.
It can be slightly reduced:
void resetStage() {
_fullLife = _halfLife = _almostDead = false;
}
I don’t like it because it generates side effects, state change, and it’s better to make it explicit and clear. State change is the worst in a code, almost all serious algorithm problems are related to state change. Even in some cases it can hinder the process of debug. But it’s the most you should do.
I think you should read about the DRY. Many people think it’s about writing less code. DRY is about being canonical and not about writing less. Writing less code is only good when the code is unnecessary or clearly repetitive, not your case, this code is great for all known patterns. To try something that seems simpler is actually to complicate more, is to express the code the wrong way, and code is expression.
Any idiot can write code that a computer understands. Good programmers write code that humans can understand
-- Martin Fowler
The solution that passes variables by reference seems intelligent (Clever, but this term is also used to indicate exaggeration in trying to look smart, is something negative, is to want to show that you know tricks), but the moment you start using you will see that it is not so good. Not to mention that the solution of the other answer is wrong. You will have to write so many overloads that will not pay. The work that will give to make these options will be greater than the use. The complication doesn’t pay off, and the weirdness makes the code less readable without any real gain. And changes will bring you problems.
If you still insisted at least you could make it right:
void boolReset(bool resetTo, ref bool b1, ref bool b2, ref bool b3) {
b1 = b2 = b3 = resetTo;
}
Remembering that if you can have only one variable you will have one more Overload, if you can have two, you will need one more, if you have 4, another. And considering that everything is the same type and that there are no combinations.
Then call it that (I will put down the original "in full" below to compare the size):
void resetStage() {
boolReset(false, ref _fullLife, ref _halfLife, ref _almostDead);
}
void resetStage() {
_fullLife = _halfLife = _almostDead = false;
}
I put in the Github for future reference.
But I still insist, even if you cannot convince, make one in each line. Increases a ;
one ENTER and the false
repeated twice, that’s all, that’s very little.
There is a way that simplifies a little, but not very much the syntax, but then the data structure will be so wrong that it is not worth considering, and it is good that nobody suggested.
You are looking at the wrong things in the code. Start paying attention to what matters.