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