Comments and Code Style

A comment is a note for humans; the compiler ignores it.

// A single-line comment

/* A comment
   spanning several lines */

val taxRate = 0.2 // a comment after code

Documentation comments (KDoc)

Comments starting with /** document a declaration. IntelliJ shows them when you hover over the name, and tools like Dokka turn them into documentation websites:

/**
 * Returns the price including tax.
 *
 * @param price the price before tax.
 * @return the price with 20% tax added.
 */
fun withTax(price: Double) = price * 1.2

What to comment

Clear names explain what code does. Comments are for why — reasoning the reader can't see:

// Bad: repeats the code
count++ // increase count

// Good: explains a non-obvious reason
// The API numbers pages from 1, so shift our 0-based index.
val page = index + 1

Kotlin style in brief

The official Kotlin coding conventions (on kotlinlang.org) are widely followed:

• camelCase for variables and functions; PascalCase for classes; SCREAMING_SNAKE_CASE for constants.
• Four-space indentation; the opening brace at the end of the line.
• Prefer val over var, and read-only collections over mutable ones.
• Prefer expression bodies (= ...) for short functions.

IntelliJ formats code to these conventions with Code → Reformat Code. In Level 2 you'll set up ktlint or detekt to check style automatically.

What's next

You now know enough Kotlin to build real programs. Try the Beginner Projects, then continue to Level 2 — Intermediate, which starts with classes.