The Golden Rules of Code Review Etiquette, as explained by teeny tiny bunnies
Tags: codereview, codequality, tutorial, programming
Published: 2021-05-19 03:00:43

Inspired by this [#DevDiscuss](https://twitter.com/hashtag/DevDiscuss?src=hashtag_click) on Twitter:

{% twitter 1394820139347070978 %}

This is the advice I gave folks in my department when starting our code review process up, and three years later, it's still going strong.

Bunny gifs are critical to the messages that follow and are included here for improved understanding of the rules.

---

![Tiny gray rabbit sitting inside in a one cup measuring cup. The ears are extra smol.](https://i.imgur.com/8sIjp46.jpg)

## Keep your review requests small and focused.

This helps your reviewer get feedback to you in a timely manner.

---

![Medium sized tan rabbit binkying on a mattress. This bun has the energy.](https://i.gifer.com/9Yv5.gif)

## Try to get to a review the same day it is requested.

Most folks depend on code for upcoming meetings, releases, and to keep moving on our ideas. Don’t let review requests sit.

---

![Small brown rabbit being showered by human. The bun looks confused and uncomfortable.](https://secureservercdn.net/198.71.233.25/6c6.158.myftpupload.com/wp-content/uploads/2013/04/Bunny-Shower.gif)

## Approve or request changes, but never comment only.

Comments don’t give the author clear direction on whether or not they can move forward. They’re great for discussion, but it’s important to be clear about next steps too.

---

![Teeny tiny brown rabbit tries to escape a coffee mug it is stuck in by wiggling back and forth. A white rabbit is nearby, completely ignoring the brown rabbit.](https://i.pinimg.com/originals/46/e5/34/46e5347c715b3a89941adcdf4143c246.gif)

## Be clear about what needs addressing.

If you request changes, be clear about what types of changes are required for approval, and what aren’t, in the overall description for your review.

---

![White rabbit with floppy ears hops down hallway, carrying a soft rabbit stuffed toy.](https://lh3.googleusercontent.com/proxy/oCWm40ylsiXBPruSpUcKfLpvjSn-eK1pzg9oucYo1bGBjvyipYTuQ6Dr_ce3saAA_uNPYtn0e3RsYckWTJ3uflqBAxxbTVGwb7-2lESry44l1ONCV4pY)

## Review with teaching in mind.

Code review is about helping each other and sharing our knowledge. Phrase your feedback and ideas in a way that helps others around you to learn more about your area of expertise! Don’t make assumptions or get frustrated. Help your coworkers improve instead.

---

![Teeny tiny baby white bunny nuzzles into an opened hand. The ears are roughly the size of your thumb.](https://i.imgur.com/et8w8Rn.gif)

## Review with empathy.

Deadlines are hard. Being new is hard. Learning is hard. We are all working to be the best people we can be, so take extra care to call out the cool ideas you see and be positive with your feedback. Use fun and appropriate emoji liberally! 🐰 Be aware of your voice and tone - humor is easily misinterpreted in text.

---

![Dark gray rabbit runs up and rudely surprises unsuspecting medium gray rabbit from behind, causing the gray rabbit to hop directly into the air.](https://media1.tenor.com/images/ea05bfda2085087687583f18e229256b/tenor.gif?itemid=7362463)

## Review with common sense.

If you get a review the same morning as a meeting or the week of launch, approve it, but leave your feedback anyway for when the designer or developer won’t be scrambling to improve things. Be deliberate about what’s okay to leave for later.

---

![Medium rabbit runs all over bed, throughout room, and straight out the door.](https://i.chzbgr.com/full/5672400896/h77E3896F/zomg-its-bunday)

## Be aware that changes introduce bugs.

Each change that has to be made can impact the stability of the code. Keep this in mind as you review around tight deadlines.

---

![Two teeny tiny fluffy white buns. One falls over backwards, as if it is absolutely, positively over this nonsense.](https://data.whicdn.com/images/217591613/original.gif)

## Don’t require perfection.

Your job as a reviewer is to act in the best interest of the code and the people you’re working with. Early on, asking someone to refactor repetitive or overly complex CSS or JS is a good call. During QA, it is not.

---

This list was taken from a code review training I ran for my department a few years ago. [Check out the full training on Google Slides.](https://docs.google.com/presentation/d/12J3eghKvTDq6dZ7EBVveDEEn6jdEF9nLt-XRGeZjjW8/edit?usp=sharing)