Reducing Code Using Kotlin

Greg Milette posted February 5, 2018

This post was co-authored by Greg Milette and Ian Stewart 

TripAdvisor has a great mobile app for vacation rental owners. Recently we made it even better by converting 33% of its code to Kotlin. One of the benefits we are seeing while doing this conversion is a reduction in code size. Having less code is good for reducing errors and lowering maintenance costs. Therefore, we care a lot that Kotlin promises to allow us to write more succinct code and reduce boilerplate.

How much code reduction?

As part of our conversion to Kotlin, we did several before and after experiments to measure the amount of Java initially present and Kotlin after conversion. In these experiments we did not change functionality at all. The code converted consisted primarily of Android Activities. Below shows the results:

# lines Java code # lines of Kotlin Percent less code
4570 4113 10%
1059 811 23%

As you can see converting Java to Kotlin has reduced the code necessary by as much as 23%. 

Kotlin features: Say more with less

Many of Kotlin’s features and libraries helped us accomplish our goals of reducing the size of our codebase as well as achieving a reduction in code size. We did this through:

Data classes:

A data class allows you to express a POJO with minimal code.

This class contains named properties as well as useful functions such as toString() and hashCode() automatically. One way we use these in our app is with Retrofit to create readable API models. They look something like this:

Data classes can have a great impact on reducing code size. The Book class previously mentioned can be expressed in a single line of code. In Java this class is more than 50 lines because it needs separate getters and setters as well as hashCode(), equals(), and toString().

Android extensions:

Kotlin has a set of Android extensions which provide convenience functions specifically designed for Android applications. For example, lots of Android files contain a list of findViewById() method calls. Wouldn’t it be nice if you didn’t have to type something like this every time you wanted to find a view in your Activity?

With the Kotlin Android extensions, you can refer to your views directly like this using the id from your layout file:

This single line is more concise. Considering an Android UI class might have dozens of these view lookups and member variables, this extension can remove a considerable amount of code. In our code base that would mean removing at least 2% of the Android-specific code. In one specific example, we had a class that contained code like the code shown below. All of these lines can be removed and replaced with a single static import using the Android extensions.


Some of Kotlin’s features can be used to create abstractions that, when applied, reduce the code needed across many classes. Delegates are one of the Kotlin abstractions that can do this by allowing a class to gain some functionality without using up it’s single inheritance.

For example in our code, all the Activity classes contained some properties that needed to be overridden, namely some identification for each Activity. Originally our code implemented this requirement using abstract methods, which each Activity needed to implement:   

Each Java-based Activity needed to have code such as the code below: 

This was not ideal. Every class that implemented these methods required two overrides, and then possibly two constants. These methods got repeated inside all the subclasses. Also, there was not a standard place within a class to put the methods and constants. Sadly, in our Java implementation we were stuck with this boilerplate code.

This was not ideal. Every class that implemented these methods required two overrides, and then possibly two constants. These methods got repeated inside all the subclasses. Also, there was not a standard place within a class to put the methods and constants. Sadly, in our Java implementation we were stuck with this boilerplate code.

To address this, in Kotlin we converted the properties to an interface:

Next, we implemented the interface via a delegate and added it to each Activity.

Finally, we added the delegate to each Activity:

These changes effectively removed about 10 lines of code from each Activity implementation and replaced it with a single line at the top of the class definition. As an additional benefit, the feature can be easily added on and doesn’t add any additional responsibilities to the abstract class. Our NamedActivity delegate is an example of how we can reduce code across many classes using a kotlin language feature not present in Java.

Optional and Named Arguments:

Optional arguments save developers from writing endless variations of a method with different options. In Java, the code needed to enumerate all the different ways other code could call a method is quite limiting. For example, in our Kotlin code we have a function that takes in four optional strings:

In Java, this would require nearly 20 lines of code instead of just a few:


These variations are not needed in the Kotlin or Java code. The code can simply leave the optional parameters out.

argKotlin can use additional variations of the function calls than the ones listed above using named arguments. Using named arguments Kotlin code can call a function with any combination of the optional parameters. For example, Kotlin code can pass in optional ument #1 and #3 and leave #2 out using this syntax:


Kotlinlib and one-line functions:

Kotlin provides some really useful shortcuts and extensions to Java classes which help to further reduce code length. Imagine that you wanted to write a function which would get the first element in a collection which met some condition you knew in advance, or which returned null if such an element did not exist. It might look something like this:

We can make it simpler by using the Kotlin function firstOrNull, which is an extension function on the Collections class.

Nice, right? This is functionally identical to what we had before, but it’s much easier to read. And we can improve it further by taking advantage of Kotlin’s single expression function syntax. Note the lack of declared return type, which Kotlin can figure out implicitly from the one line of the function.

These shortcuts are easily discoverable through the Kotlin documentation, typeahead, or through the excellent Kotlin linting tools in Android Studio.


You don’t need all that code! We’ve shown that using various Kotlin features, you can easily reduce the amount of code in your app. Less code to maintain means that engineers can focus their time on more productive activities. What’s more, creating a streamlined codebase where each line of code is needed and powerful is quite enjoyable. Thus, we envision that as our Vacation Rentals Owner App continues to transition to Kotlin we will continue to benefit from increased productivity.


Greg Milette is a Senior Software Engineer at TripAdvisor where he works on Android projects. His interests include speech recognition, mobile sensors, IoT, building scalable mobile apps, and finding a phone that has a keyboard as good as the G1. Also, Greg is the author of Professional Android Sensor Programming.

Ian Stewart is a Software Engineer at TripAdvisor.