I'm curious how it made it to the front page and if some of the folks who thought it was useful could comment about how it helped them understand how to do a code review?
To give a pretty trivial example of syntax sugar, if someone has written in C#:
var maxHeight = buildings.Select(b => b.Height).Max();
then I might point out that you can shorten it to var maxHeight = buildings.Max(b => b.Height);
whilst keeping it just as readable. Well, more readable because you need to read less characters to easily understand it. It seems pretty nitpicky but it's the kind of thing I'm delighted to be shown myself.One of the (unspoken?) tenets of XP is that if you can't have code reviews, break your code into small enough bits that you are comfortable defending each decision individually (rather than rafting them up and trying to get through 10 lines of gold and 20 lines of crap). The blast radius is tiny, and you can't as easiely confuse yourself into thinking buggy code is fine.
So there was a time where "how to do code reviews" meant "how do you cause code reviews to occur", not "what processes should you incorporate into your reviews". Maybe OP is caught in a time warp.
[0] https://kickstarter.engineering/a-guide-to-mindful-communica...
[0](https://kickstarter.engineering/a-guide-to-mindful-communica...)
A lot of people don't really know this stuff. It's nice to have a concise page to point them to.
- while giving a review, how to not focus on superficial details but instead really take the time to understand the problem and the solution. Making sure you can really understand why things were done the way they were and thinking about whether things could be made more clear, performant, follow best practices more closely, etc
- when receiving a review learning that people are reviewing it your code not you, learning how to look forward to reviews because they make your final product better
Would love to see advice on the really difficult bits of code review
Imagine you are at a unicorn with physical product already operating in public, and a C laughs at a suggestion of code review and says its too long, hard and expensive. What would you do?
This one on the human/how: https://dev.to/solidi/be-a-rockstar-at-pull-requests-1e4f
Its a subtle difference, but makes a difference in morale and code quality.