Kotlin one year after: Lessons Learnt
Its been officially one year since I started learning Kotlin and shifting all android projects that I was working on at Apps:Lab to Kotlin. Its been an awesome journey so far and in this article am going to share my experiences working with Kotlin for that one year. Am also going to highlight some of the mistakes to avoid while starting out in Kotlin.
Kotlin is a powerful language yet people without proper supervision tend to write bad code that would otherwise be impossible to be that bad in Java or any other language.
Kotlin has so many features and most of this features you only realize when you start working seriously with Kotlin. In the very beginning we had so many blog posts and articles talking of 7,10, or 13 amazing Kotlin Features that will make you make the shift to Kotlin. However, in this one year journey with Kotlin, I have come to the realization that there is more than the numbers that were pointed out. Each day with Kotlin has been a learning moment. Each day you learn a more idiomatic way to do something.
One thing I always point out is that before even making that shift, have your reasons to why you are doing Kotlin, that way it will be easier for you not to loose focus on the way and even be more exhaustive when learning the language.
Starting out in Kotlin? Here are the mistakes to avoid
With great power comes great responsibility
Kotlin being so powerful, its also very easy to go wrong on a number of scenarios. It’s up to us as developers to reroute our thinking and provide a better path for future developers especially when we run into confusing terrain.
Some of the tips am sharing in this article will apply for both guys starting out in Kotlin and those who’ve already started Kotlin.
Naming Conventions
Because val and var are all over the place and not having to define types (type inference, right), people say “oh it’s fine, the compiler knows”. Now this would be awesome and all but people very often don’t pay any sense of attention to their variable naming. It’s in Clean Code.
From what I’ve found, the code can get so terse that it’s difficult to read without IDE help (ie. what type is that val?). Also, the syntactic sugar is nice, but it can be abused easily by guys starting out. Give it a good variable name then (but not with type prefixes).
Here are some tips to proper naming of variables and properties:
- Choose Descriptive / Unambiguous Names:
2 . Names have to reflect what a variable, field, property stands for. Names have to be precise.
3. Name Methods After What They Do:
4. The name of a method should describe what is done, not how it is done.
5. Names Describe Side Effects:
6. Names have to reflect the entire functionality.
Standard Functions
With the let{} standard function being there in Kotlin standard library, at times its very easy for people to overuse it all in the name of handling nullability.
So you might say, middleName?.let { middleName ->, but most people will say middleName?.let { … and then just use it as it. Even worse when clearly non-null values are marked with ? just because they were punching ?s in until the compiler stopped giving errors.
An example:
In Java, that’s clearly:
But in proper Kotlin if someone had supervised it, it’d just be:
That was just a very tiny example, so here’s a better one showing how people can go further to misuse let {}
Keep it simple.
It isn’t to say that the examples above should never be used in practice, but it’s important to take away that as developers we should always try to keep things as simple and readable as possible. Doing so increases the information one can convey and reduces the amount of head-scratching another developer would have to do when they inevitably encounter the code.
Extension Functions
Extension functions are good, don’t overuse them. For a clear explanation of when to use and when not to use extension functions, there is this article here by Uberto Barbini that gives a clear overview of those use cases.
Infix Functions
Infix functions are good but also don’t overuse them everywhere. infixwill allow you to replace the dot when calling a method with a space, and skip the parenthesis.
For example, user.setAge(24) becomes user setAge 24. One good example is that with infix, you now can write your own Domain Specific Language (DSL) easily. Where infix can become a nightmare is when it's used everywhere in an attempt to make things more modern.
Some code examples are :
You discover this snippet of code floating around in some of your classes and you decide to create an infix function to ‘ease your work’ .
In this example, iterateList is just calling a forEach with the fancy infixsyntax. In comparison to the initial way, you can see how adding infixcomplicates the code. Not only are we adding more cognitive load to the developer , we're also adding more lines of code to the project with these small extension functions.
Newline
Newline has meaning, and reformatting your code the wrong way can cause subtle bugs
The price of having no ;s (unless you have two statements on the same line) is that now newline has meaning.
And there is an operator, the prefix unary +, which has a default implementation return this (literally there just to use it for hacky “DSLs”).
So that results in the following oddity:
BUT
Because + 5 is actually +5, which does nothing, and the + just returns what it was invoked on. If you’re concatenating spannable strings, this can hit you, because you can’t just string-interpolate those. While you can run into this very rarely, when you do, it is incredibly frustrating.
Nested if statements
Avoid chaining a couple of if statements. Prefer replacing them with expressions. For example :
Can be :
Local Returns
Know how to switch between non-local and local return
Conclusion
Some Kotlin Features look magical but its good to always know how they work in order to avoid doing the same mistakes over and over again.
There is a lot to cover and I only highlighted a couple of the things I learnt during this one year.
Meanwhile let me welcome everyone to the Kotlin happiness as I continue with my journey with Kotlin in the next year hoping to learn a lot of amazing Kotlin Features.
Please feel free to respond with any thoughts on other mistakes that I have left out and/or questions.
