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 some 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: Minimize the scope of variables
• Item 3: Eliminate platform types as soon as possible
• Item 4: Do not expose inferred types
• Item 5: Specify your expectations on arguments and state
• Item 6: Prefer standard errors to custom ones
• Item 7: Prefer null or Failure result when the lack of result is possible
• Item 8: Handle nulls properly
• Item 9: Close resources with use
• Item 10: Write unit tests

Chapter 2: Readability

• Item 11: Design for readability
• Item 12: Operator meaning should be clearly consistent with its function name
• Item 12: Operator meaning should be clearly consistent with its function name
• Item 13: Avoid returning or operating on Unit?
• Item 14: Specify the variable type when it is not clear
• Item 14: Specify the variable type when it is not clear
• Item 15: Consider referencing receivers explicitly
• Item 16: Properties should represent state, not behavior
• Item 16: Properties should represent state, not behavior
• 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 property delegation to extract common property patterns
• Item 22: Reuse between different platforms by extracting common modules

Chapter 4: Abstraction design

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

Chapter 5: Object creation

• Item 30: Consider factory functions instead of constructors
• Item 31: Consider a primary constructor with named optional arguments
• Item 32: Consider defining a DSL for complex object creation

Chapter 6: Class design

• Item 33: Prefer composition over inheritance
• Item 34: Use the data modifier to represent a bundle of data
• Item 35: Use function types instead of interfaces to pass operations and actions
• Item 36: Prefer class hierarchies to tagged classes
• Item 37: Respect the contract of equals
• Item 38: Respect the contract of hashCode
• Item 39: Respect the contract of compareTo
• Item 40: Consider extracting non-essential parts of your API into extensions
• Item 41: Avoid member extensions

Part 3: Efficiency

Chapter 7: Make it cheap

• Item 42: Avoid unnecessary object creation
• Item 43: Use inline modifier for functions with parameters of functional types
• Item 44: Consider using inline classes
• Item 45: Eliminate obsolete object references

Chapter 8: Efficient collection processing

• Item 46: Prefer Sequence for big collections with more than one processing step
• Item 47: Limit number of operations
• Item 48: Consider Arrays with primitives for performance-critical processing
• Item 49: Consider using mutable collections

Dictionary