Not enough information.
New team member? Show them the style guide and where it doesn’t match.
Is the style guidelines consistently followed elsewhere? If not, I’d just approve it.
Do I have a good relationship with the other developer, and can they handle criticism? If not, I probably would not want to be the one reviewing it, but if I did I would likely let it go and fix it later. Fight more important battles.
Otherwise, how important is that piece of code? I’d immediately approve a one-off script, but if it’s an core piece of code, I assume the dev missed it and point it out. Happens to everyone.
etc. etc.
Putting Ctrl in the home row by replacing the useless Caps-Lock is sufficient for me .
Alt is easily reached with the thumbs and shift is already close enough to the home row, with shift-ctrl using both pinkies.
If being against murder, war crimes, and genocide is being an antisemite, then so be it. I will be a proud antisemite. It will be a badge of honor.
You could make the same argument for voting. What does your little drop in the vote bucket matter? Do you believe voting is a waste of time too?
Some developers seem to enjoy making their code obscenely difficult to understand, either because it actually makes sense to them that way, or because it makes them feel smarter.
Be wary about this mindset. This type of explanation sets you up for conflicts with existing developers. Several times I’ve seen developers coming into a team and complain about the code, creating conflicts that can last the entire working relationship for no good reason.
Much of the time the people who constantly work with code are already aware of the problems and may not be happy with it, but there’s no time or big benefit in improving working code. Or it’s complicated for good reasons which may not be immediately apparent. (ie. inherent complexity).
Here are a couple of benign reasons which probably will serve you much better.
It’s much more difficult and time consuming to make code that is easy to understand. Even in open source, there’s a limited amount of time to spend on any particular thing. This explanation is like a variation of Twain’s “I didn’t have time to write a short letter, so I wrote a long one instead.”, or more abrasively Hanlon’s razor “Never attribute to malice that which is adequately explained by stupidity time pressure”.
When writing the code, the developer has the entire context of his thought process available. You don’t have that, and that’s also the reason why your own code can make no sense a while later. Also it’s just much harder to read code than to write it.
Your answer doesn’t give confidence that you care about how the code looks. Could imply that you’re sloppy. Some people are very opiniated about style and think it matters a lot. They would be unhappy with people who say it doesn’t really matter.
They’d likely welcome fixes or comments on style. Other people would be very angry if you held up their PR with such trivialities.
I had strong style preferences when I was younger, but after working on so many projects with different styles I really don’t care anymore about any particular style. I just make sure to seamlessly match the style of the code around it.