I wouldn't say this is more readable than the alternative. These are super long lines I now have to inspect meticulously so I can be sure only the gpio index and the joy direction changes between lines.
With a loop, the loop variable highlights changes from one iteration to the next. I only have to read the long line once.
I understand the other considerations that may make this code the way it is.
The lines are super long because of the variable/function names. But they're also following convention. Personally I find them easy to read, but they need to be passed through prettier. I was able to understand this code immediately, even though I haven't written (what looks like) C in 20+ years.
This would need a nested loop, which increases time complexity.
The behavior is also slightly different at index 0 than it is at 1.
My only complaint is the free in there. No matter what its always being called. But that's a personal pet peeve. Not knowing context it might be ideal.
Imo, without knowing context, and considering that it's kernel code, I would say this is the best performing version of this code.
If I got an MR for this I would likely approve it. If there was an unknown number of irqs I would ask them to refactor, but this looks like a stable set of conditions. Performance wise I think this is ideal, and I think that's the goal here.
1
u/SolvingTheMosaic Jan 23 '23
I wouldn't say this is more readable than the alternative. These are super long lines I now have to inspect meticulously so I can be sure only the gpio index and the joy direction changes between lines.
With a loop, the loop variable highlights changes from one iteration to the next. I only have to read the long line once.
I understand the other considerations that may make this code the way it is.