Kotlin in a Team: Code Style and Conventions Everyone Argues About

Kotlin in a Team: How to Stop Arguing About Formatting and Start Writing Code

Have you ever conducted a code review where half the comments boiled down to "add a space," "remove a space," or "why are you using CamelCase instead of snake_case"? If so — welcome to the club. In any team, the question inevitably arises: Kotlin code style and conventions. And if you don't agree in advance, everyone will drag in their own "perfect" bracket placement.

This article is not a dry list of rules. It's a practical guide on how to make Kotlin code readable, uniform, and convenient for the entire team. We'll cover key conventions, automation tools, and life hacks that will save you hours of arguments on calls.

Why Code Style in Kotlin is Not About Aesthetics, But About Money

Let's be honest: the business doesn't care whether you put the opening brace on the same line or a new one. But the business does care how much time it takes to onboard a new developer into the project. Studies show that developers spend up to 40% of their time reading code. If the code is written in a unified Kotlin code style, this process speeds up significantly.

When a project uses a unified Kotlin code style:

\n
• New team members understand the project structure faster.
\n
• Code reviews go faster — reviewers look for logic errors, not spaces.
\n
• The number of bugs due to incorrect formatting decreases (yes, that happens too).
\n
• Git diffs become cleaner — less noise from reformatting.
\n

Therefore, Kotlin conventions are not a whim of the lead, but a tool for increasing efficiency. And now we'll break down how to implement them without pain.

Official Guide: Kotlin Coding Conventions

Let's start with the basics: JetBrains has an official document — Kotlin coding conventions. It's not a law, but wise people recommend it as a starting point. Let's go over the key points that most often cause arguments.

Naming: CamelCase Forever

Kotlin uses CamelCase for everything: classes start with a capital letter (MyAwesomeClass), functions and variables start with a lowercase letter (myAwesomeFunction). Top-level or object-internal constants use SCREAMING_SNAKE_CASE. No underscores in variable names — this isn't Python.

// Correct\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// Incorrect\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData

Braces: Opening on the Same Line

Kotlin follows the Java tradition: the opening brace is on the same line as the declaration. This is not up for debate unless you want to be considered a heretic.

// Kotlin way\nfun processData(data: List<String>) {\n    data.forEach { item ->\n        println(item)\n    }\n}\n\n// Non-Kotlin way (but if the whole team writes this way — ok)\nfun processData(data: List<String>)\n{\n    data.forEach { item ->\n        println(item)\n    }\n}

Spaces: Don't Skimp on Them

Put spaces after keywords (if, for, when), around binary operators, and after commas. This improves readability.

// Readable\nif (x > 0 && y < 10) {\n    println("Hello, World!")\n}\n\n// Hard on the eyes\nif(x>0&&y<10){\n    println("Hello, World!")\n}

Auto-formatting: Your Best Friend

Manual code style checking is a thing of the past. Kotlin has a built-in formatter in IntelliJ IDEA: Ctrl+Alt+L (or Cmd+Option+L on Mac). But if someone on your team uses VS Code or another editor — problems are inevitable.

The solution: ktlint and Spotless.

ktlint: The Universal Soldier

ktlint is a tool that checks and automatically