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.
I had to shorten the title, but some of the information you say is missing is actually covered on the question.
Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like “Whatever style decision is important should be covered in the style guide. If you don’t have a style guide, then I’d assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I’d rather spend time working on new features and shipping than arguing over style preferences.”
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.
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.
I had to shorten the title, but some of the information you say is missing is actually covered on the question.
Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like “Whatever style decision is important should be covered in the style guide. If you don’t have a style guide, then I’d assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I’d rather spend time working on new features and shipping than arguing over style preferences.”
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.
You’re hired!
Great! When can I start?