Reviewing code is an essential part of development process. It helps to avoid having issues on development branches and release candidates and take care of app’s architecture.
I want to share with you some of points that I check when I have to review my or my peers’ code.
It sounds like a college statement but it doesn’t matter how experienced you are, you can always have logic errors. That’s why it is good to understand and check all the conditions of the code that you are reading.
Null Pointer Exceptions
One of the most common types of crashes that are in the wild while you develop are caused by trying to run methods on objects that are not instantiated (a.k.a. NullPointerException).
Although some of them are obvious to find in the code there are some that are hidden under backend responses or your architecture design and those are the ones that we have to keep in mind.
We are developers and because of that we love creating new pieces of code. It is also common to think that writing new code is going to be easier to understand, implement and many other things.
The truth is that by reusing code we contribute to keep the app’s code simpler and avoid having new crashes on production.
Even if you are working alone or with a big group of people, code standards matter. So, reviewing pull requests is a great time help maintaining the code standards and to coach new developers in the team to get use to it.
Nowadays all startups and big companies (or even yourself) want to track things to understand users’ behavior, improve the app and why not to make money.
Sometimes in the rush of coding new features or refactoring code we don’t pay attention to trackers and “the pull request moment” is a great opportunity to detect if we are missing to add some trackers or accidentally removed some.
Saving the App’s State
One of the things we tend to forget is saving the app’s state and when that happens (after switching between apps, getting the app killed or rotating the phone) we loose the state of what the user was doing. So, this is something to take into account when reviewing code.
One of the trickiest part of Android development is to keep simplified layouts and stick to what the design team have designed. It is important to pay attention to the amount of views and nested views used to keep the layout simple without compromising what was designed.
Dimens, Strings and Constants
Once you have unified all your dimens, strings and constants on each file you will find out how easy is to modify values and behaviors of the app.
It is important to avoid hardcoding values on every file of the app to keep simplicity on code and happiness of the other fellow developers.
Selectors, On Boarding and Details
In the rush of coding fantastic code solutions we are prone to forget about details.
It is important to have apps that give feedback, teach and respond to users on a way they feel secure of their actions and what is going to happen next.
Remember to check for pieces of code that represent those kinds of details.
Although it is obvious, not everyone speaks the same language around the globe.
Next time you check some pull requests take into account the languages that your app supports and make sure you are providing accurate translations for each of them.
Even some of this things are obvious, it is important to have them on a checklist (printed or inside your head) to help improving the quality of your apps.
There are some other stuff to take into account but I haven’t added them to avoid having an extensive list. Please, don’t hesitate to let me know what other things you check in code reviews or any other thoughts.
Resume of what to check on Android pull requests
- 💻 Logic Errors
- 🚫 Null Pointer Exceptions
- ♻ Code Reuse
- 🌐 Code Standards
- 🔎 Tracking
- 💾 Saving App’s State
- 🔵 Simplified Layout
- 🆎 Dimens, Strings and Constants
- 💎 Selectors, On Boarding and Details
- 🇦🇷 Localization
Did you like what you have read?
Recommend this story (by tapping the ❤ button) so other people can read it!
You can also react on Twitter: @santihollmann