Software Quality: Hating other people’s code

It’s all fun and games when looking at someones else code before you notice that it’s the code you wrote a few months ago. Now you know you have to fix that block of code, and you send it for review. But what’s this review?

5 stars ⭐⭐⭐⭐⭐, would use this fix again

Me reviewing someone elses code

Code reviewing

Nope, code reviewing is not giving stars or a score if you like or not the code… well, in part, it is. But it has other objectives other than complaining about code. Code review has the goal for other people to check your code, and if everything seems to fine to them, then your code can be pushed into the project (5 stars). If there is something wrong, a possible bug, format errors, or maybe you used tabs instead of spaces, your peers can ask you to modify and improve your code (1 star).

Why code review?

Two heads think better than one

popular phrase

Everyone has always heard this phrase, and in this case is totally true.

When coding, it is complicated to consider all things involved in your code, maybe because your codebase maybe is humongous, or you have tons of stuff to do because, or you had that one meeting that takes you out of the zone. So maybe you made a mistake, or you didn’t consider an edge case, or it was just a typo.

Fun side story: In Facebook, they have the story that once a programmer made a typo in one URL and wrote faceboook (yes, with 3 o), and it passed all their controls, so when it reached production, the real Facebook was redirecting to Faceboook, and at the time it was a scammer site, and they crashed it because it didn’t support all the traffic normal Facebook had.

So because a person can’t consider everything nor being perfect while coding, it’s beneficial to have someone else look at your code. When one of your peers looks at it, they can detect possible errors, typos, or maybe just have questions on why you did something one way instead of another. All this helps developers grow because they learn from their mistakes, and the conversations that start from those comments can also give knowledge to the commenter.

How to Code Review?

First of all you need to be working as part of a team, so there could be someone else to review your code!

As you’re working, and you think you finished a functionality, milestone, task, or some kind of goal, then it is time to send this for review.

It’s important to remember that the smaller is the code you send to review, the easier it’s for review, so please keep your pull requests (diffs, or whatever you use) small. I will say that less than 200 lines are good enough, but it would be best if less than 100 (you can split your code in more than one review as long as everything stays consistent and working).

After you send your code, and your peers decide to review it (if you are me, then you’ll have to beg them for reviews because they tend to be busy 😭), they will start to give you comments, recommendations and ask questions on the decisions you took.

If there are comments, then is your work to answer them, correct whatever is needed, and resubmit for review.

If everything goes well this time, your peers were busy enough to just think everything was good and accept your changes, or most probably they really reviewed them, and you rock it!

Now it’s time to submit your code to the main codebase!

NOTE: remember that you still need to do tests as you submit code and wait for all tests to pass before merging to main. Peer reviewing is not an alternative for this 🙂

A visual representation of these steps: