# Bad Kotlin Extensions

DevFeed: [Bad Kotlin Extensions](<https://devfeed.tech/articles/bad-kotlin-extensions-38646.md>)

Original publisher: [Read original article](<https://krossovochkin.com/posts/2021_01_25_bad_kotlin_extensions/>)

Published: 2021-01-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Vasya Drobushkov](<https://devfeed.tech/sources/vasya-drobushkov.md>)

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

Tags: [article](<https://devfeed.tech/tags/article.md>), [code](<https://devfeed.tech/tags/code.md>), [extensions](<https://devfeed.tech/tags/extensions.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [readability](<https://devfeed.tech/tags/readability.md>)

## AI overview

This article explains how overusing Kotlin extension methods can make code harder to read. It defines the benefits and costs of extensions and examines overly clever public extensions, including an operator-overloading factorial example, that may increase readers' cognitive load.

## Source excerpt

Introduction Kotlin extensions are a cool feature. Though trying to write 'idiomatic' Kotlin code some developers tend to overuse that feature making code worse than it could be without extensions. In this article, we'll go through some examples of how not to write Kotlin extensions. First of all, we need to try to define what a good extension is. It is simple though vague: good extension solves some problems. When we talk about code the main feature extensions have is to improve readability. Extension methods are static methods with the first parameter being a receiver of the extension. For example, these are equivalents: