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.”
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.”
You’re hired!
Great! When can I start?