How Code Quality Is Measured: Android Code Review at Yalantis

Programmers are the authors of great builds just as writers are the authors of bestselling novels. But behind the scenes, there are always many people who contribute to the process. A bestselling novel takes more than just a writer. Editors, publishers, and marketing teams do a lot of hard work that’s often unnoticed.

The best coding – like the best products of any type – is the result of collaboration. And all programmers – both veteran and beginner – need somebody else to adequately proof-read their work. This is how we ensure code quality at Yalantis.

We started doing code reviews for iOS and Android projects a couple of years ago. This process increased the quality of our code and streamlined our app development process. We have four main goals that we achieve with code review. Let us show you why they matter.

Goals of code review and how we achieve them

Risks that we avoid Our goals How we achieve our goals Benefits of code review Producing sub-par code.Creating Yalantis coding culture.By introducing code review as a regular practice.Guaranteeing high-quality products.

1. Unexpected app behavior.

2. Critical bugs going unnoticed.

3. App crashes in final production.

4. New functionality being difficult to add.

Defect-free, well-documented software.

1. Code reviewers detect errors in the application logic when a project is still in its infancy.

2. Developers redesign application architecture if needed.

3. The whole team improves code quality.

The earlier a bug is found, the cheaper it is to fix.Another developer having to spend a lot of time using and modifying existing code in the future.Software that complies with Yalantis coding standards.All developers learn Yalantis code style conventions.

1. App development speeds up when all developers are using one coding standard.

2. Software is cheaper to maintain.

Lack of expertise sharing among developers.

Sharing knowledge between developers.

All developers regardless of their level and experience review code of their peers.

Sharing knowledge improves both the overall quality of software and the developers’ skills.

Code review can be complicated, like smuggling live tropical snakes through an airport. But reviewing somebody else's code can be more complicated still – like being forced to explain to airport officials why you're smuggling live tropical snakes (and why you shouldn't be arrested).

We wrote code review guidelines and tutorials for our Android team to make the process of code review smooth and transparent. Our guides are based on Android code review best practices and techniques to improve code quality. 

Our code review process involves line-by-line code analysis, a source code review checklist, and documentation for suggesting improvements. Let's see how to do code review for Android.

Code analysis

1. Documentation and coding style.

Poorly written code can cost countless hours and significant resources. Comprehensive documentation and strict coding style are extremely important. The simpler your code is, the simpler it will be to maintain your code in the future.

At some point you may find yourself supporting an already existing application, or substituting a developer. Developers who didn’t initially work on the project need to clearly understand every single line of code. The clearer the documentation, the faster the app development, and the fewer resources your organization will spend.

Some comments in code might not make any sense. Or they can be written in a foreign language. Our company standard is to use English for all comments, even though English is not our native language.

We use English for two reasons:

  1. Android app developers from other countries might use our source code in the future.

  2. We are an active contributor to Android open source software widely used by other companies around the world. Check out uCrop, our latest open source image cropping library for Android, and see other iOS and Android open source projects.

Code styling and naming conventions make Android code more understandable. We have Android code guidelines of our own. If you don’t have a coding style in your organization, you can use Android coding guidelines for contributors as a basis. And of course, “Clean Code: A Handbook of Agile Software Craftsmanship” has an extensive set of recommendations on clean coding and code styling .

You can automatically check your code against Android coding guidelines and styling using Checkstyle. This code review tool has plugins for Android Studio and Jenkins.

Here’s a snippet of code from our uCrop project (below) to show how we name fields and methods, and how we write comments:

    public static final float DEFAULT_MAX_SCALE_MULTIPLIER = 10.0f;
    private final RectF mCropRect = new RectF();
    private final Matrix mTempMatrix = new Matrix();

    private float mTargetAspectRatio;

     * This method changes image scale for given value related to point (px, py) but only if
     * resulting scale is in min/max bounds.
     * @param deltaScale - scale value
     * @param px         - scale center X
     * @param py         - scale center Y
    public void postScale(float deltaScale, float px, float py) {
        if (deltaScale > 1 && getCurrentScale() * deltaScale <= getMaxScale()) {
            super.postScale(deltaScale, px, py);
        } else if (deltaScale < 1 && getCurrentScale() * deltaScale >= getMinScale()) {
            super.postScale(deltaScale, px, py);

2. Architecture patterns.

Our Yalantis developers follow the Model-View-Presenter (MVP) architectural pattern for Android app development. When we do code review for Android projects, we check if the MVP pattern is implemented correctly (i.е. business logic is decoupled from the view layer).

Sometimes, we do review of Android source code written by other developers who don’t follow the MVP pattern. In this case, we check the general adequacy of their approach, and the purity and correctness of the connections between the components of the application.

Most systems work best if they are kept simple rather than making them complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.

Kelly Johnson


3. Error handling.

Error handling is crucial for any software project. We can’t avoid all negative scenarios, and so we need to handle them in the most graceful way. We check if the code we are reviewing considers all possible errors arising from user input, server responses, and database transactions.

Error handling isn’t only about logging detected errors. Quite often error handling also involves informing the user about what exactly went wrong in the application and how the issue can be resolved.

Here is a piece of code from a Presenter class that illustrates API request with RxJava that handles both the result and possible errors by calling proper methods in the corresponding View class:

                .subscribe(new Action1<User>() {
                    public void call(User user) {
                }, new Action1<Throwable>() {
                    public void call(Throwable throwable) {
                        Timber.e(throwable, "requestUser");

4. Test coverage.

Even though we rely heavily on our QA team for successful build releases, we don’t pass code into production until we have written tests for the specific functionality we are implementing. The “test early” principle helps us detect and fix bugs early in the life cycle of our projects.

During Android code review, we see what percentage of the code is actually covered by our unit tests. We pay most attention to unit testing business logic, but we run UI tests as well. According to Lars Vogel’s tutorial on developing Android unit and instrumentation tests:

  • 70-80% of tests should be unit tests to ensure stability of your code base
  • 20-30 % of tests should be functional tests to ensure that the application really works.

5. Performance monitoring.

Even though mobile technology is rapidly developing, the processing power of the average Android devices is still limited, memory is finite, and battery capacity continues to be one of the most precious resources. If we don’t monitor code performance, the product we are developing may not pass muster when it launches on the market.

App performance depends not only on the reliability of Android source code, but also on third-party SDKs, operating systems, devices, network constraints, data services, and APIs that support the app.

To discover what causes specific performance problems, we need to take a look under the hood. We use Performance Profiling Tools for Android to collect data about an app's execution. We also use simulators with diagnostic capabilities to quickly pinpoint the root causes of failures when something goes wrong.

For example, if during Android source code review we discover that an app sends frequent requests to the server, we will do clever http caching. If an app causes significant battery drain, we'll make sure it doesn’t ask location services for unnecessary updates.

With the best code review tools always at our fingertips we can constantly monitor the quality of our products.

6. Security.

The goal of our security code review of Android projects is to detect security vulnerabilities and find weaknesses. The source of these weaknesses can be insufficiently secure coding policies or flaws in the business logic, in internal structures, or in the system’s design.

For example, during security checks we see if a program uses HTTPS/SSL protocol for data transfer between server and client, verify that these data are encrypted, and check if the code itself is obfuscated.

Our security code review reveals security bugs and hidden backdoors in the code.

Possible outcomes of Yalantis code review

For each code review we create an Android code review checklist and suggest code improvements that can be boiled down to five types of solutions:

  1. Refactoring to make code cleaner, and therefore, more reliable and maintainable.
  2. Detecting the root cause of problems and fixing these problems.
  3. Rewriting some parts of code.  
  4. Optimizing operations with a database or an API library or changing the library.
  5. Rewriting the project from scratch.

Let us know if you have any questions about Android code review. We’re always happy to help.

Read also:


4.1/ 5.0
Article rating
Remember those Facebook reactions? Well, we aren't Facebook but we love reactions too. They can give us valuable insights on how to improve what we're doing. Would you tell us how you feel about this article?
Want to improve your app?

We can help you save your project from sinking

Contact us

We use cookies to personalize our service and to improve your experience on the website and its subdomains. We also use this information for analytics.

More info