This code gives the right answer - it is not wrong. Repetition reduces code quality but not its correctness.

Now, I would never write code like this, but if I were reading through a codebase and saw this, I'd be - paradoxically - happy.

The code is correct. It's clear. It's a tiny bit inefficient, but so what?

If I were reviewing it, I would suggest at least getting rid of the unnecessary comparisons, sure, but I have seen code so, so, so much worse than this.

I worked with a brilliant, warped programmer once (and I mean a nasty fucker as well as writing bad code). He had the stated belief making code hard to understand was better because it means only smarter people could work on the codebase.

He would send out code reviews with 40 or 50 tiny commits with useless messages like "Update code" ("Don't worry, I'll squash them all at the end), with 20k lines of code difference. He had a private convention for local variable names that he wouldn't ever explicate. All of them started off sle, for "serialized ledger entry", which would have been bad anyway, but none of these variables were ever serialized, and few of them were ledger entries.

Oh, and at the time, he had a foveal code theory where he would break lines as soon as he could after 40 non-whitespace characters.

(He was also a vaccine denier, climate crisis denier, a gross sexist, and the first Trump supporter I had ever met, this being 2014. Just a complete bag of shit, Vinnie was. I started to get panic attacks for the first time in my life after a couple of years of working for this maniac.)

So yes, I'd trade all of that brilliant, incomprehensible code for duller, stupider, more easy to understand and maintain code, like the mediocre example here.

The funny part is that no one actually pointed out the real bug - the incoming value is not a percentage, 0% <= x <= 100%, it's a ratio, 0.0 <= x <= 1.0. By calling it a percentage, one day someone's going to give it a number 100x too big...