New rules — Android Clean Code
In developer life, we have to admit that we spend 30% of working time to read your code — but sometimes it’s going to be your f**king code. In every-tech company might have code guidelines or standard to control code quality. It usually bases on the team, favorite or reasonable. Luckily, the “Clean Code” book by Robert C. Martin can help us regarding code guidelines.
The “Clean Code” book was the first release in 2008; it provides a lot of recommendations, suggestions, and examples of coding. “Clean Code” gives us the example of programming in general. It bases on OOP technic and writer’s working experiences which is a pretty handy book.
Android SDK also released in 2008; it still using JAVA at that time. At this point, you will notice that the “Clean Code” guidebook again can adapt to the Android development world. However, Android itself has some specific way to implement. The “Clean Code” is not going to fit all. That’s why I come up with new rules.
I’ve got new rules; I count ‘em.
In the “Clean Code” book, it categorizes rules by the alphabet for i.e.
Comment category
C1: Inappropriate Information
C2: Obsolete Comment
C3: Redundant Comment
I also apply the kind of groups to new rules.
Android Framework
A1: Don’t use deprecated code
Android also has the “Support Library”; to help us handle Android’s fragmentation. Some of the code might be deprecated. In term to avoid the runtime bug try not to use deprecated code or treat it appropriately.
A2: Coding in wrong thread
Coding on Android sometimes we have to do background jobs, and developer’s common mistakes are trying to update a view from the background jobs. Therefore, it will cause a runtime error.
A3: Avoid to manipulate view in the code
Not recommend adding a new view programmatically instead of described in an XML file because it might hard to update the view later. Alternatively, the developer makes mistakes by adding view in wrong Activity/Fragment Lifecycle.
A4: Wrong Lifecycle
All Android developers have to know the term called “Lifecycle.” but not all developer handle it correctly, sometimes you may writing some specific code in a wrong lifecycle; it will lead you a problem.
A5: Avoid ProGuard in a specific package
ProGuard is an excellent tool; it avoids some of lousy guy revert engineer your code. There are two sides of a coin, it also a troublemaker if you do not write ProGuard rules carefully. ProGuard is going to obfuscate your code. If you don’t want to obfuscate some path of your code for, i.e., parameters in API call. You have to specify ProGuard rule and move all the API parameters class under the package that ProGuard cannot touch.
XML
X1: Don’t use deprecated code
XML also has the deprecated code, try to solve it carefully. Or use the Android resource to separate the version of supported XML.
X2: Too deep of XML
If you declare more than 7 levels of XML; it slows down your application significantly.
X3: Always use resource ID
Do not hardcoded in the XML file. Always use resource ID instead.
X4: Fixed size in single number does not support big or small screen
It, not a right approach to specifying sizes of view, due to the Android phone has many screen sizes. It is going to make a layout break in some screen ratio.
X5: Child and parent do the same thing
In this case, if the attribute in the parent layout and its child show the same result. That means the parent is unnecessary. You can remove it to avoid too many levels of XML (X2)
X6: Use styling
Try not to set the attribute of styling; please create a style instead. This way make your app has a consistent style, and also easy to update the style.
X7: Use an appropriate layout
If you use an inappropriate layout, it may lead you to “Too deep XML (X2)” or memory leaks for, i.e., declare “RecyclerView” as a child of “NestedScrollView.” So “RecyclerView” is not going to recycle the view anymore. When you use the “inspect layout tools” you can see all of the items in the list render. If you have many items or your items is full of images it easily to lead the memory leaks problem.
Am I come up with the rules by myself?
No, the rules that I set it has set by reasons. I usually collect it from common lint warn, error, or IDE suggestion. I also find the reason why it shows up the waring then create the rules and share it with the team. Moreover, the rules have been set to achieve the goals; readable code, maintainable code, and testable code. As long as it achieves these goals, I’ll add to my new rules.
Conclusion
Code review, and reading the old code it might pain in the ass if you do not write code with style. We always have Robert C. Martin’s book as our guidelines but it not covers all cases. We have to come up with new reasonable rules. All of these is my new rules so far, feel free to use it or write what’s your thought in the comment section down below.
Thanks
— end of story —
