Kotlin: Coding Conventions - A Solved Problem

In Java, "code style" is something teams argue about. Google style or Sun style or the AOSP one? Tabs or spaces? Where do the braces go? Plenty of wiki pages and pull-request threads have died on these hills.

Kotlin skipped the argument. It shipped with one official set of conventions on day one — and the company that designed the language also designs the IDE that enforces them. So in Kotlin, style isn't a debate you have. It's a setting you turn on.

Consistency Isn't Cosmetic

A consistent codebase reads faster, diffs cleaner (no noise from someone's reformatting), and onboards new people quicker — they learn one style, not five. It also frees code review for what actually matters: the logic, not the brace placement.

This matters most on a team that's half ex-Java developers, each arriving with their own deeply-worn habits. Without a shared, enforced style, a Kotlin codebase slowly fills up with five different accents.

There's One Official Answer

You don't need to invent a house style or hold a meeting about it. JetBrains publishes the official Kotlin coding conventions — naming, formatting, file layout, the lot. Adopt it as-is.

This is the opposite of the Java world, where the competing style guides are themselves a thing to choose between. In Kotlin, the choice is already made. The rest of this article is about making your tools enforce it so you never have to think about it again.

Let Your IDE Enforce It — for Free

Here's the part most "Kotlin style" guides skip: you don't memorize these rules, your IDE applies them. And it's all in the free edition — Kotlin's tooling isn't a paid feature.

In IntelliJ IDEA (Community or Ultimate) or Android Studio:

1. Apply the official style. Settings → Editor → Code Style → Kotlin → Set from… → Kotlin style guide.
2. Turn on formatting checks. Settings → Editor → Inspections → enable Incorrect formatting. (Naming inspections are on by default; this one isn't — so switch it on.)
3. Reformat on demand. Cmd/Ctrl + Alt + L reformats the file and Cmd/Ctrl + Alt + O optimizes imports. Better still, enable format-on-save so you never think about it.

To share the style with your whole team, add one line to gradle.properties:

kotlin.code.style=official

New projects created by the IntelliJ wizard set this for you. Commit it, and every developer's IDE applies the same rules — no "works on my machine" formatting wars.

Make It Stick in CI, Not Just on Your Laptop

IDE settings keep you consistent. To keep a team consistent — and block style drift before it merges — push enforcement into the build:

• ktlint — a linter and formatter built on the official conventions. It checks style in CI and can auto-format with ktlintFormat.
• detekt — static analysis that catches code smells and complexity, with formatting rules available too.
• .editorconfig — a single file that both the IDE and ktlint read, so your rules live in the repo and travel with it.

Wire ktlint into CI, and a badly-formatted pull request fails the check instead of becoming a review comment. The style stops being anyone's job.

The Conventions Worth Knowing by Heart

You won't memorize the full rulebook — that's what the tooling is for. But a handful are worth internalizing, especially coming from Java:

Naming

class UserRepository          // PascalCase for classes and objects
fun fetchActiveUsers() { }    // camelCase for functions and properties
const val MAX_RETRIES = 3     // UPPER_SNAKE_CASE for compile-time constants
package com.example.billing   // lowercase packages, no underscores

Files and layout — A Kotlin file can hold several related declarations; you're not forced into Java's one-public-class-per-file rule. Name the file in PascalCase after its main content (or its theme if it holds several things).

Formatting — Four-space indentation (never tabs), no semicolons, and prefer expression bodies (fun double(x: Int) = x * 2). Trailing commas are allowed and keep diffs clean.

Packages — Don't reflexively recreate Java's deep com.company.project.feature.subfeature nesting. Flatten it where the extra layers add nothing.

Where to Go Deeper

These are the rules you'll lean on daily; the official Kotlin coding conventions cover the complete set — documentation comments, modifier order, chained-call wrapping, and more. Bookmark it as the reference.

One section of that page — Idiomatic Language Features (immutability, scope functions, and friends) — is really about how you write Kotlin, not how you format it. I covered those in Idiomatic Kotlin: Lose the Java Accent. Conventions keep your code consistent; idioms keep it Kotlin.

Set It Once, Then Forget It

Consistency in Kotlin is a setup task, not a discipline task. You don't need willpower or a style police — you need to flip a few switches once: apply the official style, turn on the inspection, add kotlin.code.style=official, and let ktlint guard the gate.

Do that, and formatting stops being something you think about — which is the whole point. Your attention belongs on the code, not the commas.