Clean Code, Idioms & Professional Workflow

What you'll learn

Knowing the language is one thing; writing code other professionals respect is another. This module is about craft and workflow — writing idiomatic Kotlin, keeping it clean automatically, collaborating with Git and code review, and shipping safely with CI/CD.

By the end you'll be able to:

• Write idiomatic, expressive Kotlin
• Enforce style automatically with ktlint and detekt
• Collaborate with a Git branch → PR → review workflow
• Understand CI/CD and basic security hygiene

Idiomatic Kotlin

Idiomatic Kotlin leans on everything you've learned: prefer val over var, expressions over statements, immutable data, and null safety over defensive checks. Compare a Java-style function with its idiomatic rewrite:

// Java-flavoured Kotlin — works, but not idiomatic
fun describe(user: User?): String {
    if (user == null) {
        return "no user"
    }
    var result = ""
    if (user.isActive == true) {
        result = "active: " + user.name
    } else {
        result = "inactive: " + user.name
    }
    return result
}

// Idiomatic Kotlin — concise, immutable, null-safe
fun describe(user: User?): String {
    user ?: return "no user"                    // early return with Elvis
    val status = if (user.isActive) "active" else "inactive"  // if-expression
    return "$status: ${user.name}"             // string template, immutable val
}

Formatting & linting

Don't argue about style — automate it. ktlint enforces the official Kotlin style guide and can auto-format, while detekt is a static analyzer that flags code smells, complexity, and potential bugs. Wire them into Gradle so every build stays consistent:

./gradlew ktlintCheck     # verify formatting against the style guide
./gradlew ktlintFormat    # auto-fix formatting issues
./gradlew detekt          # static analysis: find code smells & bugs

Git & GitHub workflow

Professional work flows through Git. The everyday loop: create a branch for your change, make small focused commits with clear messages, push, and open a Pull Request so a teammate can review before it merges to the main branch:

git checkout -b feature/add-login    # a branch for your change
git add .
git commit -m "Add login screen"     # small, focused, well-described commit
git push -u origin feature/add-login
# then open a Pull Request so a teammate can review it

Code review & CI/CD

Code review catches bugs, spreads knowledge, and keeps quality high — approach it with humility on both sides. CI (Continuous Integration) automatically builds and tests every push, so problems surface immediately; CD (Continuous Delivery/Deployment) automates releasing that verified code. A typical CI pipeline runs ktlint, detekt, and your full test suite on every Pull Request — nothing merges unless it's green.

Security fundamentals

Every developer shares responsibility for security. The essentials:

• Never hard-code secrets — keep API keys and passwords out of source control; use environment variables or a secrets manager
• Validate all input — never trust data from users or the network
• Use parameterised queries — never build SQL by string concatenation
• Keep dependencies updated — outdated libraries carry known vulnerabilities
• Prefer HTTPS and least privilege — encrypt in transit; grant only the access that's needed

Recap & quick check

That completes Phase 7 — you now code and collaborate like a professional. All that's left is to prove it. In the final phase you'll build a portfolio of real Kotlin projects. 🚀