The purpose of this book

To really unleash the advantages of Kotlin, we need to use it properly. To do so, not only do we need to know about different Standard Library (stdlib) functions but even more, we need a good understanding of Kotlin features, purpose, and design. The main goal of this book is to explain how to use different Kotlin features to achieve safe, readable, scalable, and efficient code. Since this book is written to help developers get better at writing code, it also touches many general rules for programmers. This book tries to compose as much knowledge about best practices in Kotlin as possible. You can call it a collection of best practices.

For whom the book is written

This book is not teaching basics. It assumes that you have enough knowledge and skills to do Kotlin development. If you don’t, I recommend starting first from resource designed for beginners.

Effective Kotlin is directed to experienced Kotlin developers. Though I will assume that even experienced developers might not know some features. This is why I explain some concepts like:

• Property
• Platform type
• Named arguments
• Property delegation
• DSL creation
• Inline classes and functions
• Tail recursion

I want this book to be a complete guide for Kotlin developers on how to become an amazing Kotlin developer.

Main parts of the book

Concepts in the book are grouped into three parts. Each part is divided into chapters, which are subdivided into item. Those parts are:

Good code

More general rules about making good quality code. This part is for every Kotlin developer, no matter how big their project is. It starts from items about safety and later talks about readability. It is not a coincidence that the first chapter is dedicated to safety. I believe that program correctness generally is of the highest priority, and safety is an important component. Readability is another item because the code is not only for a compiler but also for programmers. Even when we work alone, we want code that is readable and self-explanatory.

Code design

This section is for developers creating a project together with other developers, or creating libraries. It is about conventions and setting contracts. It will, in the end, reflect on readability and safety, but all in terms of correct code design. This part is a bit more abstract at the beginning, but thanks to that it can explore topics that are often omitted in books about code quality. This section is also about preparing our code for growth. A lot of items are about being ready for changes in the future. Therefore it is an especially important section for developers creating large projects.

Efficiency

This section is for developers that care about code efficiency. Most of the rules presented here do not come at the cost of development time or readability, so they are suitable for everyone. However, they are particularly important for developers implementing high-performance applications, libraries, or applications for millions.

Table of contents

Introduction: Be pragmatic

Part 1: Good code

Chapter 1: Safety

• Item 1: Limit mutability
• Item 2: Eliminate critical sections
• Item 3: Eliminate platform types as soon as possible
• Item 4: Minimize the scope of variables
• Item 5: Specify your expectations for arguments and state
• Item 6: Prefer standard errors to custom ones
• Item 7: Prefer a nullable or Result result type when the lack of a result is possible
• Item 8: Close resources with use
• Item 9: Write unit tests

Chapter 2: Readability

• Item 10: Design for readability
• Item 11: An operator’s meaning should be consistent with its function name
• Item 12: Use operators to increase readability
• Item 13: Consider making types explicit
• Item 14: Consider referencing receivers explicitly
• Item 15: Properties should represent a state, not a behavior
• Item 16: Avoid returning or operating on Unit?
• Item 17: Consider naming arguments
• Item 18: Respect coding conventions

Part 2: Code design

Chapter 3: Reusability

• Item 19: Do not repeat knowledge
• Item 20: Do not repeat common algorithms
• Item 21: Use generics when implementing common algorithms
• Item 22: Avoid shadowing type parameters
• Item 23: Consider using variance modifiers for generic types
• Item 24: Reuse between different platforms by extracting common modules

Chapter 4: Abstraction design

• Item 25: Each function should be written in terms of a single level of abstraction
• Item 26: Use abstraction to protect code against changes
• Item 27: Specify API stability
• Item 28: Consider wrapping external APIs
• Item 29: Minimize elements’ visibility
• Item 30: Define contracts with documentation
• Item 31: Respect abstraction contracts

Chapter 5: Object creation

• Item 32: Consider factory functions instead of secondary constructors
• Item 33: Consider a primary constructor with named optional arguments
• Item 34: Consider defining a DSL for complex object creation
• Item 35: Consider using dependency injection

Chapter 6: Class design

• Item 36: Prefer composition over inheritance
• Item 37: Use the data modifier to represent a bundle of data
• Item 38: Use function types or functional interfaces to pass operations and actions
• Item 39: Use sealed classes and interfaces to express restricted hierarchies
• Item 40: Prefer class hierarchies instead of tagged classes
• Item 41: Use enum to represent a list of values
• Item 42: Respect the contract of equals
• Item 43: Respect the contract of hashCode
• Item 44: Respect the contract of compareTo
• Item 45: Consider extracting non-essential parts of your API into extensions
• Item 46: Avoid member extensions

Part 3: Efficiency

Chapter 7: Make it cheap

• Item 47: Avoid unnecessary object creation
• Item 48: Consider using object declarations
• Item 49: Use caching when possible
• Item 50: Extract objects that can be reused
• Item 51: Use the inline modifier for functions with parameters of functional types
• Item 52: Consider using inline value classes
• Item 53: Eliminate obsolete object references

Chapter 8: Efficient collection processing

• Item 54: Prefer Sequences for big collections with more than one processing step
• Item 55: Consider associating elements to a map
• Item 56: Consider using groupingBy instead of groupBy
• Item 57: Limit the number of operations
• Item 58: Consider Arrays with primitives for performance-critical processing
• Item 59: Consider using mutable collections
• Item 60: Use appropriate collection types

Dictionary