In the routines of every app developer, we must have to adopt some good practices which can be useful for improving our code quality as well as coding skills
Sometimes we have to check the code standard for ourselves as well as for others
There are some major points that can’t be ignored, so let’s discuss some basic checklists during code review.
Performance is the priority for every application, some corners may reduce the performance of the application like infinite loops, needless threads etc
- Object allocation is often called function which can be moved to somewhere else
- Reducing the application size also improves the performance
- Work Efficiently with Threads
- Data synchronisation is crucial and must be executed in a proper way
- Improve memory usage by avoiding memory leaks
- Optimise drawable used in the project, utilize vector as much as possible
Some points can be checked at the time of any module implementation in the application
- During an Android App Development, it’s necessary to follow some architectural patterns.
- Also, we need to take care of the project’s coding style guide.
- At the time of implementation, we must check that there is any code which will become obsolete after changes.
- Sometimes code becomes useless and can be deleted after the changes.
Accessibility and Usability
Usability attracts the users so the usability of the app should be proper
- In almost every case, for design, designers provide the design. We have to check If the User Interface matches them or not.
- For every individual view have we used the proper classes? Almost every screen has a back button so the proper view is ImageButton, not an ImageView so we need to check that.
- Does the color of any design match the exact colors or not?
- Fonts you have used are from the company’s branding or not.
- As we have many android devices, the market has many different sizes, so we have to check whether it will be proper with every device or not.
- Nowadays almost every device supports dark mode, whether our app will look good with dark mode or not.
- Some users modify the font size from the device, we also need to check that it will be proper or not.
- In some devices, the custom fonts are not supported like some fonts in some other languages, so I also have to look into it.
- At the time of exporting files from design, you need to take care about size, some low graphics devices can not handle the high graphic images.
Error Handling and Management
We can say that error is an event that disturbs the normal operation. Every developer should handle all the possible known errors;
- Display a proper error message to a user is a necessary thing, Colour also matters while showing some messages, generally, colour with red contrast is used to show an error message
- Message specification is also required sometimes we need to avoid some error messages like ‘Something went wrong’ and ‘Try again’
In some cases where we have to display error messages to use
- If your app requires a network connection and the device is not connected to the internet
- Sometimes API call fails due to any reason, we need to show an error message with the proper reason
- Sometimes in input fields, users enter unexpected things like special characters in the name, characters in the mobile number field etc
- Sometimes we asked for permission and the user denies that permission, at that time we have to show some specific message which every user can understand
- When the device connection is slow, and the PI calling task is taking longer than expected, at that times we have to show the proper error message
Some cases where developers need to show the log into logcat
- As we have discussed above, colour matters a log while logging also, use the proper colours logging the event, like it is an error shown in red, cases passed shown in green etc need to be taken care of
- Some non-fatal errors should be logged
- Some error which catches the exception should be logged
- Some flows which can lead to some complex functionality need logging to track the flow
- We need to hide some log which reveals the crucial information of the user, in this case, we can do it in a proper manner in the debug mode we show the logs but hide them in the release builds
Generally, dependency means the Gradle build system makes it reliable to include external libraries or some modules in our build. Every developer use the dependency in the day to day life, it is either some necessary or some third-party dependency, so while adding dependency we need to think about some points
- Think how necessary the dependency is? Sometimes we need a few classes and we add the whole dependency to the project like some modules provide lots of animation but we need one or two of them, at that time we need to avoid adding a dependency to our project
- Also, some module has so many class in them, it will increase the size of the APK
- Before choosing the dependency we always need to check the alternatives, for the image picker library, we have lots of options available, but we always have to choose the one which is actively maintained and who is maintaining it
- As android is introducing something new in every version, will a dependency be compatible with it or not?
- If we have used proguard in our app, so after adding a particular dependency, the app will work as expected or not
- The major point, after updating a compile or target SDK version, will dependency works flawlessly or not?
Code readability should be proper as we got the project again in maintenance after a few years, we must get the idea about the functionality by reading the code,
- The best practice is to write a related comment on every function
- For writing comments, we should follow documentation engine format like Javadoc
- We also need to check at the time of changing a code, whether the comment written is still accurate or not
- Is there any lambda function which needs to be declared explicitly
- If some params require resource annotations then we have to declare it in a proper manner like for string resource we can use @StringRes etc
- Naming convention is also a major important thing
- We also need to look at the Named function arguments we must have to assign if it would be helpful
- Check for places where some unnecessary explicit types are used
Testing and Testability
Some Testability related things are mentioned below
- Code is testable or not?
- Some classes that will be added or modified can be easily mocked or not?
- Suppose your project uses UI testing, you should check if UI test is added and updated if already exists
- Are there any test cases which can become inaccurate after modifying code changes?
- Are there any test cases which can be deleted after modification?
That’s it for now, hope you consider basic checkpoints while reviewing android code