> Any issues of style should be in the style guide. Anything not in the style guide can be ignored. Or the style guide should be updated.
I find that there are two components of style:
- Formatting
- Clean abstractions, modularization... everything else that goes into making you a great (not just passable) programmer
Formatting should be handled by tools like others have said. For everything else I have the options:
- Turn the style guide into a book which no one will ready anyway
- Ask them to read an actual book but it isn't practical in the scope of a PR, and even after reading the ideas take a while to digest
- Attempt to mentor the employee via the PR, often appearing pedantic because it's hard for a novice to appreciate what they don't know.
- Code that passes CI is working code - screw everything else!
I take the mentoring route whenever it's presented to me but have generally found that some other team members (especially as they get older) have no interest in best practice and become annoyed by the code review process. If the mentee has persistence it tends to work out but moreso over 6mth-1yr timeframes. For mentees without the patience we drop the code review and keep them in areas of the code base where they can't do too much damage.
I guess what I'm trying to say is that our culture is willing to bend the processes to fit individual's strengths, and overall our workplace is pretty happy/chill. Maybe the engineering quality takes a hit but I can definitely sympathize with where the OP is coming from.
I find that there are two components of style:
- Formatting
- Clean abstractions, modularization... everything else that goes into making you a great (not just passable) programmer
Formatting should be handled by tools like others have said. For everything else I have the options:
- Turn the style guide into a book which no one will ready anyway
- Ask them to read an actual book but it isn't practical in the scope of a PR, and even after reading the ideas take a while to digest
- Attempt to mentor the employee via the PR, often appearing pedantic because it's hard for a novice to appreciate what they don't know.
- Code that passes CI is working code - screw everything else!
I take the mentoring route whenever it's presented to me but have generally found that some other team members (especially as they get older) have no interest in best practice and become annoyed by the code review process. If the mentee has persistence it tends to work out but moreso over 6mth-1yr timeframes. For mentees without the patience we drop the code review and keep them in areas of the code base where they can't do too much damage.
I guess what I'm trying to say is that our culture is willing to bend the processes to fit individual's strengths, and overall our workplace is pretty happy/chill. Maybe the engineering quality takes a hit but I can definitely sympathize with where the OP is coming from.