DEV Community

Cover image for My opinion on what makes a good Code Review.

My opinion on what makes a good Code Review.

Grant Riordan on May 08, 2022

Why do we do Code Reviews? Code review is simply what it says on the tin. It is the opportunity for other developers to look at your cod...
Collapse
 
simeg profile image
Simon Egersand 🎈

Good points! I prefer giving concrete examples about names rather than use terms like "more descriptive". What's descriptive is subjective and I've been in situations where the PR author doesn't know what to change it to.

Tests is one thing I keep an eye out for. If there are none I don't approve it unless for good reasons πŸ™‚

Collapse
 
jeremyf profile image
Jeremy Friesen

This is great advice and a reminder of the pull request reviewer's role: gatekeeper. Without their approval the code doesn't get merged. With their approval it can get merged. And everyone reviewing code should understand this positional power.

The review is the time of inviting others to help shoulder the burden of maintaining the "main" branch. It is a distinctly collaborative moment that both shapes and reflects the state of the code base. Review with a robust concern for the code quality and for the person offering the code.

Adding to the list:

  • Does the code contain any "surprises"? Are those documented/commented?
  • Does the code "duplicate" something else in the code-base?
  • Are there "magic numbers and strings" that would be better served as a constant or named variable?
Collapse
 
joelbonetr profile image
JoelBonetR πŸ₯‡
Change this variable name

is objectively more clear and concise than

Perhaps this could be worded to a more descriptive variable name.

But I too usually fall into the second while trying to be polite πŸ˜‚

Please, use a more accurate and descriptive identifier for this variable.

Except this time I declined a PR that used random generated numbers to IDENTIFY things πŸ˜… The guy come and said that it worked in hims machine and that mathematics are exact science. I've lost 30min explaining why this is true unless you add randomness into the algorithm.

Sorry for the long comment, that's to say that CRs are fine but most of the time we need to group together with the juniors (and not so juniors) to make them truly understand what was wrong as mentoring process.
I always try to enforce KISS as base principle, then comes SOLID, guidelines and so.

Collapse
 
sgrilux_41 profile image
sgrilux

Totally agree. The other day I got a comment on my MR about a trailing space.

Collapse
 
deathwaiting profile image
ahmed galal

Java developer, My reviewer usually points outs me over complicating things like:

  • using too much streams
  • using too much var keyword
  • using records
  • using Stream.toUnmodifibleSet() unnecessaryly
  • using a class for representing Money (Currency + Bigdecimal) instead of just using BigDecimal

Is that what they mean by KISS πŸ˜…?

Collapse
 
vikbert profile image
Xun Zhou

if you got the comments such as "using a class for representing Money" several times, it might be a good idea to talk about it in another dev-jourfix or retro meeting. The goal is to clarify if your team can do a design decision together, if we apply an ValueObject Money instead of using BigDecimal generally. If yes, just put such thing into your team coding convention. Then everything will be easier in the future.

Collapse
 
andrewbaisden profile image
Andrew Baisden

This is really sound advice everybody has a different way of doing a code review.

Collapse
 
dionarodrigues profile image
Diona Rodrigues

Great article!

Collapse
 
alihanima profile image
alihanima

Excellent points! Rather of using phrases like "more descriptive," I like to give real examples of names. What is descriptive is subjective, and I've been in instances when the PR writer is stumped. iogames-free.com

Collapse
 
josavicente profile image
Josa Vicente

Very good points! On my team we take in consideration all this points! πŸ₯°