[pc86]

The title of the article is "How to do code reviews" yet all the content is around why code reviews are done and what the goals are. And the content itself is pretty light - the second half is just rehashing the first half, which are all bullet points.

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?

[n4r9]

I agree and even then I think it misses some major goals of code reviews. For example, encouraging thinking about good coding style (as opposed to just "standards"), making use of the language's syntax sugar where it makes things more readable, and the underlying performance.

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.

[hinkley]

Some of us still recall when code reviews were more of a concept than a practice you actually did at work every day.

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.

[yepthatsreality]

Agreed it was a pretty poor read, no matter how many emojis the author uses. The linked material is a bit better. [0]

[0] https://kickstarter.engineering/a-guide-to-mindful-communica...

[finaliteration]

Agreed. I found the referenced article[0] far more useful as a guide for how rather than why.

[0](https://kickstarter.engineering/a-guide-to-mindful-communica...)