A Code Reviewer’s Checklist for Android Projects

Points to keep in mind when reviewing Android codebases

Photo by Lala Azizli on Unsplash

Code review is a tedious process sometimes, but I believe that we need to spend more time on that. Maybe it is an opportunity for you to learn or share some knowledge.

I listed some points that I consider necessary to check in a code review process on Android projects.

Memory Leaks

Imagine the following case: a beautiful app but a slow one at the same time, the navigation between the screens is getting slower each time.

Some points to check during the code review:

• Is there any Context retention on this new piece of code?
• Is there any RxAndroid code related? If yes, check if the RxCalls are being disposed of at the end of the lifecycle scope (ViewModel/Fragment/Activity).
• If the code has coroutines, check if the Job is launched from the ViewModel scope to be released correctly.
• Is the code a kind of implementation using CountDownTimer, AsyncTask, or any video/audio player? If yes, the code should be releasing the memory resource related to avoiding leaking.
• Is it a new Fragment with ViewBinding approach, the code should release the binding at the onDestroyView method.

Reference: https://developer.android.com/topic/libraries/view-binding

Deep Layouts

Sometimes we have a ViewGroup that has another ViewGroup as a child.

A good suggestion is always to use as ViewGroup ConstraintLayouts to keep the layouts flatter. It can avoid overdraw, which causes performance issues.

There are some tips mentioned in the Android docs to reduce overdraw.

Resource Annotations

Each resource in the Android world has an identifier, which is an Integer type. How to make sure that our Integer value represents a valid resource id? The annotations help us in this matter.

For example:

In the code above, the reviewer could suggest: “What do you think to use annotations? Something like that:” (show an example):

Other examples of annotations: here.

Similar Components

It is so important to invest time during the code reviews. Try to think as the author thought, reflecting his choices, making questions to understand the code.

A new code is coming. Wait: “This code is doing the same of we already have in this component”. Comments like this are essential because the great thing is reusing what already exists in our code base. Pay attention when the components are something like:

• Component X changes the moon color to red 🔴;
• Component Z changes the full moon to blue 🔵;
• Component A changes the moon to green 🍏.

Why not a component to change the color of any moon? It can receive the color as an argument. Is it too much work?

Danger Code Zones

If you have a sensitive code — I like the expression danger zone, which describes better this situation. The danger code is the code that the reviewer looks at and gives a reaction like: “This code doesn’t make any sense”.

In this case, don’t judge the author. Talk to them to understand the reason behind that code. This talk could be an opportunity to learn something new.

Architecture Violation 📐

Software architecture is a communication protocol defined between parts of the software.

Code review is a very effective arm to identify issues like architecture violations. Adding comments like these are good in such scenarios:

• “Friend, your ViewModel is accessing the repositories. We have a UseCase between them. Please, take a look at the file MainViewModel, which is a great example.”
• “Why are you using an Adapter reference inside of your ViewModel? An adapter is a RecyclerView component. It would be better to put this in a Fragment and keep it far from our ViewModel.”

Small details make the difference

• Not used imports;
• Not used resources such as drawables, strings, colors…
• Commented code;
• Not formatted code;
• Variable names, method names, file names, …
• Code not following a style guide. For example, Kotlin defines a well-defined style guide. It helps a lot for any developer to find quickly any software component in an existing codebase.

Conclusion

Static analysis tools are helpful in a code review process, but they are not 100% effective. A critical developer review is indispensable if your team is looking for code quality.