kotlin-development

SKILL.md

Kotlin Development Best Practices

General Principles

Use English for all code and documentation

Always declare the type of each variable and function

Avoid the any type; create necessary types instead

No blank lines within function bodies

Naming Conventions

Case Standards

PascalCase: Classes, interfaces, enums

camelCase: Variables, functions, methods, parameters

UPPERCASE: Environment variables, constants

underscores_case: Files and directories

Naming Guidelines

Start each function with a verb (get, set, create, update, delete, etc.)

Use complete words over abbreviations

Allowed abbreviations: API, URL, i/j for loops, err, ctx, req/res/next

Avoid magic numbers; define constants instead

Boolean variables use prefixes: isLoading, hasError, canDelete

Function Design

Size and Responsibility

Keep functions under 20 instructions

Each function should have a single responsibility

Extract logic into utility functions when complexity increases

Naming Functions

Use verb-based naming that describes the action

Prefix boolean-returning functions with is, has, or can

Prefix void functions with action verbs like execute, save, send

Reducing Nesting

Use early returns to handle edge cases first

Extract nested logic into separate functions

Employ higher-order functions (map, filter, reduce) to minimize loops

Prefer arrow functions for simple operations; use named functions otherwise

Parameters

Use default parameters instead of null checks

When functions have multiple parameters, consolidate them into objects (RO-RO pattern)

Keep parameter lists short (max 3-4 parameters)

Data Handling

Data Classes

Use data classes for data structures

Encapsulate primitive types in composite types when they represent domain concepts

Validate data internally within data classes

Immutability

Prefer immutability for data

Use val for variables that don't change

Use immutable collections when possible

Create new instances instead of mutating existing ones

Classes and Objects

Size Guidelines

Keep classes under 200 instructions

Limit to fewer than 10 public methods

Limit to fewer than 10 properties

Design Principles

Follow SOLID principles

Favor composition over inheritance

Use interfaces for abstraction

Keep classes focused on a single responsibility

Exception Handling

When to Use Exceptions

Reserve exceptions for truly unexpected errors

Don't use exceptions for control flow

Catch exceptions only to:

Fix an anticipated issue

Add context before re-throwing

Best Practices

Create custom exception types for domain-specific errors

Include meaningful error messages

Log exceptions at appropriate levels

Testing

Unit Tests

Follow Arrange-Act-Assert convention

Write unit tests for all public functions

Use test doubles (mocks, stubs, fakes) for dependencies

Name tests descriptively to document behavior

Acceptance Tests

Follow Given-When-Then convention

Test user-facing behavior and scenarios

Keep tests independent and repeatable

Code Organization

Group related functionality together

Keep files focused and cohesive

Use packages/modules to organize code by feature or layer

Maintain consistent file structure across the project