Kotlin 101: A Beginner's Guide to Variables, Functions, and Control Flow

When you first open a Kotlin file, the syntax looks clean—no semicolons, no checked exceptions, and a refreshing lack of boilerplate. But soon you face a choice: val or var? Why are there two ways to write a function? And how do you handle conditions without falling into nested if-else hell? This guide answers those questions by showing you the reasoning behind Kotlin's design and the pitfalls to avoid. We'll cover variables, functions, and control flow in a way that builds a strong foundation for real projects.

Why Kotlin's Approach to Variables Matters

Kotlin's variable system is one of its most distinctive features. The language encourages immutability by default, which reduces bugs and makes code easier to reason about. But many beginners misuse var when val would work, or they overlook the implications of type inference.

Val vs. Var: The Immutability Principle

val declares a read-only reference—you can assign it once and never change it. var allows reassignment. The rule of thumb: always start with val. Only switch to var if you have a clear reason to mutate. For example, a counter in a loop needs var, but a configuration value should be val. This habit prevents accidental state changes and makes your code more predictable.

Type Inference: When to Specify Types

Kotlin infers types from the right-hand side. You can write val name = "Alice" and the compiler knows it's a String. However, sometimes explicit types improve readability—especially for public API functions or when the inferred type is not obvious. A common mistake is relying on inference for complex expressions, which can lead to unexpected types. For instance, val result = someFunction() might return a nullable type when you expected non-null. Adding an explicit type catches such mismatches early.

Null Safety and the Elvis Operator

Kotlin's type system distinguishes between nullable and non-nullable types. A variable declared as String? can hold null; String cannot. This forces you to handle null explicitly. The safe call operator ?. and the Elvis operator ?: are your tools. For example: val length = text?.length ?: 0. A typical beginner error is forgetting to handle null when calling methods on a nullable variable, leading to compilation errors. Always think: "Can this be null?" and use safe calls or the !! operator only when you are certain it's non-null.

Lazy Initialization and Delegates

Sometimes you need a variable that is initialized only when first accessed. Kotlin provides by lazy for val and lateinit for var. lateinit is common in dependency injection or Android onCreate. A pitfall: accessing a lateinit property before initialization throws an exception. Always ensure initialization happens before use. lazy is thread-safe by default, but you can change the lock mode. Use it for expensive computations that may not be needed.

Functions: Writing Clean, Reusable Code

Functions are the backbone of any program. Kotlin offers a concise syntax, default parameters, and extension functions, but these features can be misused. Understanding the "why" behind function design helps you write code that is easy to read and maintain.

Function Syntax and Expression Bodies

A standard function looks like: fun sum(a: Int, b: Int): Int { return a + b }. But if the body is a single expression, you can omit the braces and return: fun sum(a: Int, b: Int) = a + b. This is called an expression body. Use it for simple functions to reduce clutter. However, if the expression is long or involves multiple lines, stick to a block body for clarity. A common mistake is using expression bodies for complex logic, making the code hard to debug.

Default and Named Arguments

Kotlin allows default parameter values: fun greet(name: String, greeting: String = "Hello") = "$greeting, $name!". Named arguments let you skip optional parameters: greet(name = "Bob"). This reduces overload methods. A pitfall: changing a default value in a library can break clients if they rely on the old default. Also, be careful with order—mixing positional and named arguments can confuse readers. Use named arguments for parameters with the same type to avoid ambiguity.

Extension Functions: Adding Behavior Without Inheritance

Extension functions let you add methods to existing classes: fun String.isEmail() = this.contains("@"). They are resolved statically, not dynamically. Beginners often think they modify the class, but they are just syntactic sugar for static utility functions. Overusing extensions can lead to code that is hard to find—prefer them for clearly separable operations. For example, adding a toSlug() extension on String is fine, but adding business logic as an extension on a domain class may obscure the flow.

Higher-Order Functions and Lambdas

Kotlin treats functions as first-class citizens. You can pass lambdas to functions like filter, map, and forEach. A lambda syntax: list.filter { it.length > 3 }. The implicit it parameter is convenient but can reduce readability in nested lambdas. Use explicit parameter names when the lambda is complex. Another mistake is capturing mutable variables in lambdas, which can cause unexpected behavior in concurrent contexts. Prefer immutable captures or use thread-safe constructs.

Control Flow: Making Decisions and Looping

Control flow structures in Kotlin are expressions, not statements. This means they can return values, which is a shift for many developers. Understanding this distinction helps you write more concise and expressive code.

If as an Expression

In Kotlin, if can be used as an expression: val max = if (a > b) a else b. There is no ternary operator; the if expression fills that role. A common mistake is using if as a statement when an expression would be cleaner. For example, instead of: var result: String; if (condition) { result = "yes" } else { result = "no" }, write: val result = if (condition) "yes" else "no". This eliminates mutable variables and reduces lines.

When: A Powerful Replacement for Switch

The when expression replaces Java's switch with more flexibility. You can match on values, types, or conditions: when (x) { 1 -> "one"; in 2..10 -> "small"; is String -> "string"; else -> "other" }. A pitfall is forgetting the else branch when when is used as an expression—the compiler requires exhaustiveness. Also, when without an argument acts as a cleaner if-else chain: when { score >= 90 -> "A"; score >= 80 -> "B"; else -> "F" }. Use this to avoid deeply nested ifs.

Loops: For, While, and Ranges

Kotlin's for loop iterates over anything that provides an iterator: for (item in collection) { ... }. Ranges like 1..10 are inclusive, while 1 until 10 excludes the end. A common error is using .. when you need until, causing off-by-one bugs. while and do-while work as expected. Prefer for with ranges or collections over index-based loops for readability. For example, for (i in 0 until size) { ... } is clearer than a while loop with a counter.

Break and Continue with Labels

Kotlin supports labeled break and continue to exit nested loops: outer@ for (i in 1..3) { for (j in 1..3) { if (i == j) break@outer } }. This is more readable than using flags. However, overusing labels can make code spaghetti. Use them sparingly, and consider extracting the inner loop into a function that returns a result instead.

Scoping and Visibility: Where Your Variables Live

Understanding scope is crucial to avoid variable shadowing and unintended access. Kotlin has block scope, class scope, and package-level scope. Visibility modifiers (public, internal, protected, private) control access. A frequent mistake is declaring variables with too wide a scope—prefer the most restrictive visibility that works. For example, use private for helper functions and constants. Also, be aware of shadowing: a local variable with the same name as a member variable hides the member, which can cause confusion. The IDE warns about this, but it's easy to overlook.

Local vs. Member Variables

Local variables are declared inside functions or blocks. They should be used for temporary state. Member variables (properties) hold state for an object. A common anti-pattern is using a property when a local variable would suffice, leading to unnecessary object state. For instance, a counter used only inside a loop should be local. Conversely, a configuration value that is used across methods should be a property.

Package-Level Functions and Properties

Kotlin allows top-level functions and properties outside a class. This is useful for utility functions. However, overusing package-level declarations can lead to a cluttered namespace. Group related functions in a class or an object. Also, package-level val or var are compiled into static fields—be mindful of initialization order and thread safety if they are mutable.

Common Pitfalls and How to Avoid Them

Even experienced developers make mistakes when learning Kotlin. Here are some frequent pitfalls and strategies to avoid them.

Overusing the !! Operator

The !! operator converts a nullable type to a non-null type, throwing a NullPointerException if the value is null. It's often used as a quick fix to satisfy the compiler, but it undermines null safety. Instead, use safe calls, the Elvis operator, or explicit null checks. Reserve !! for cases where you are absolutely certain the value is non-null, such as after a previous null check that the compiler cannot infer.

Misunderstanding Smart Casts

Kotlin's smart casts automatically cast a variable after a type check: if (obj is String) { println(obj.length) }. However, smart casts work only when the variable cannot change between the check and the use. If the variable is a var that could be modified by another thread, smart cast is disabled. In such cases, use an explicit cast or assign to a local val first.

Ignoring the Cost of Collections Operations

Kotlin's standard library provides many convenient functions like filter, map, and forEach. But chaining them can create intermediate collections, impacting performance on large datasets. Use sequences (asSequence()) to defer execution and avoid intermediate collections. For example, list.asSequence().filter { ... }.map { ... }.toList() processes elements lazily. A common mistake is using sequences for small collections where the overhead outweighs the benefit—measure if performance matters.

Mini-FAQ: Quick Answers to Common Questions

When should I use val vs. var?

Always start with val. If you find yourself needing to reassign the variable, consider whether a different design (like creating a new object) would be better. Use var only for mutable state that is truly necessary, such as loop counters or accumulators.

Can I use if as a statement and an expression?

Yes. When used as a statement, the result is ignored. As an expression, the result must be assigned or used. The compiler enforces that the expression has an else branch if the type is not Unit. Prefer expression form to reduce mutable variables.

What is the difference between == and ===?

== checks structural equality (calls equals()), while === checks referential equality (same object). For most types, use ==. For comparing nullable types, == handles null safely. === is rarely needed except when comparing with null or checking object identity.

How do I handle multiple conditions without nested ifs?

Use when without an argument for boolean conditions, or when with a subject for value matching. For complex logic, consider extracting conditions into separate functions with descriptive names. Avoid deeply nested if—it reduces readability.

Next Steps: From Basics to Real Projects

Now that you understand variables, functions, and control flow, it's time to apply them. Start by writing small programs that use these constructs: a calculator, a to-do list manager, or a simple text analyzer. Practice using val over var, expression bodies, and when expressions. As you gain confidence, explore Kotlin's standard library—collections, sequences, and scope functions like let, apply, and run. These will help you write more idiomatic code.

Remember that learning a language is a journey. Don't try to master everything at once. Focus on writing clear, correct code first, then optimize for conciseness. Use the Kotlin Playground (play.kotlinlang.org) to experiment without setting up a project. Join community forums like the Kotlin Slack or Stack Overflow to ask questions when stuck. Finally, read Kotlin code written by others—open-source projects on GitHub are great resources. With practice, you'll find Kotlin's design choices make your code safer and more expressive.