# An opinionated guide on how to make your Kotlin code fun to read and joy to work with

DevFeed: [An opinionated guide on how to make your Kotlin code fun to read and joy to work with](<https://devfeed.tech/articles/an-opinionated-guide-on-how-to-make-your-kotlin-code-fun-to-read-and-joy-to-work-with-25931.md>)

Original publisher: [Read original article](<https://proandroiddev.com/an-opinionated-guide-on-how-to-make-your-kotlin-code-fun-to-read-and-joy-to-work-with-caa3a4036f9e?source=rss-7a8d96da8cb6------2>)

Author: Gabor Varadi

Published: 2021-02-15T06:16:05Z

Content type: tutorial

Language: en

Sources: [Stories by Gabor Varadi on Medium](<https://devfeed.tech/sources/stories-by-gabor-varadi-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [code](<https://devfeed.tech/tags/code.md>), [code-style](<https://devfeed.tech/tags/code-style.md>), [guide](<https://devfeed.tech/tags/guide.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [maintainability](<https://devfeed.tech/tags/maintainability.md>), [readability](<https://devfeed.tech/tags/readability.md>)

## AI overview

An opinionated guide to writing Kotlin code that is easier to read and maintain. It recommends formatting multi-argument constructors across lines, using let mainly in assignments or return statements, avoiding it for general control flow or side effects, and replacing implicit lambda arguments with meaningful names in complex expressions.

## Source excerpt

I've been meaning to write this article in a while. Hopefully, the following tips and style recommendations (in no particular order) will help you write better Kotlin! Let's get on with it, shall we? For 2 or more constructor arguments, prefer not to keep the properties on the same line as the class name in the constructor definitionclass MyClass( val a: A, val b: B, ): MyParentClass(a, b), MyInterface { // ... } This format is preferable, because when adding the 3rd argument, important bits (such as a possible base class or interface) can appear too far on the right side of the screen. Listing them one after the other (including the trailing comma since 1.4.21+) allows for better readability and extensibility (reducing the chance of causing merge conflicts with future code changes, for example). Prefer to use the scoping function 'let' only in assignments or return statements, but NOT as general control flow, or a "quick rename to 'it'" Oftentimes, Kotlin code tends to do something like this: fun myMethod(nullableA: A?) { nullableA?.let { // no it.x() // no it.y() // no it.z() // no } } (Note: in a method like this, A? could be replaced with A to take advantage of typed nullability, this is just an example.) To allow better maintainability and readability, we should instead prefer to only use ?.let { in simple assignments, or return statements, but not as general control flow. For example, the following chain is easy to understand: val protoClass = savedInstanceState?.getByteArray("protoValue") ?.let { ProtoClass.parseFrom(it) } However, in this case, ?.let { is part of an assignment. Also, while ?.let { can be chained with a ?: to provide a default value (especially in combination with takeIf) it shouldn't be used to execute side-effects (also is more suitable for that). In fact, it needs to be said: x?.let {} ?: run {} is NOT a general purpose replacement for if-else statements and null-checks, and should never be used in this particular format for that purpose!