Kotlinのコーディング規約について

Kotlinのコーディング規約は、単なるコード整形ルールではなく、可読性・安全性・一貫性を高水準で維持するための設計思想として定義されています。

本記事では以下を前提に整理しています。

• Kotlin公式 Coding Conventions
• Android公式 Kotlin Style Guide
• 実務で一般化している設計・運用指針

そして重要なのは、「公式に明記されているルール」と「現場で推奨されている慣習」を混同しないことです。

Kotlinコーディング規約の基本思想

Kotlinの規約は、次の価値観を強く重視しています。

• 読んだ瞬間に意図が分かること
• IDE（IntelliJ / Android Studio）の自動整形と相性が良いこと
• Null安全・不変性を自然に促すこと
• Java開発者が違和感なく読めること

そのため Kotlin では「短く書ける」よりも「意味が明確である」ことが常に優先されます。

命名規則（Naming Conventions）

クラス・インターフェース・object

class UserRepository
interface UserService
object AppConfig

• UpperCamelCase（パスカルケース）
• 基本は名詞
• 責務・役割が明確に分かる名前を付ける

補足（重要）

Kotlin公式では、Manager や Wrapper などの意味が曖昧になりやすい語を例として挙げ、「目的が不明確な命名を避ける」ことを推奨しています。

// 曖昧（非推奨になりやすい）
class UserManager

// 具体的でOK
class UserSessionManager
class UserSyncManager

「Manager がダメ」なのではなく、何を管理しているかが名前から分かることが重要です。

関数・変数

fun calculateTotalPrice()
val userName: String
var isEnabled: Boolean

• lowerCamelCase
• Boolean は is / has / can などで始める
• 不要な略語は避ける（cnt より count）

定数（const val）

const val MAX_RETRY_COUNT = 3

• UPPER_SNAKE_CASE
• const val は
  トップレベル / object / companion object で使用する
  （ローカル変数や通常クラスのインスタンス領域では使えない）

※これはコーディング規約というより Kotlinの言語仕様に基づく制約。

インデント・フォーマット

基本ルール（公式）

• インデントは4スペース
• タブは使用しない
• { は行末、} は対応するブロックと同じインデント

if (condition) {
    doSomething()
} else {
    doAnotherThing()
}

これは Kotlin公式・Android公式の両方で共通しています。

1行の最大文字数について（重要）

ここは 規約が分かれるポイント です。

• Android公式 Kotlin Style Guide
  • 1行 100文字以内 を明確に規定
• Kotlin公式 Coding Conventions
  • 固定の文字数上限は明示していない

したがって正確には次の扱いになります。

• Android開発：100文字上限を採用
• サーバーサイド / 共通Kotlin：チーム規約に委ねる

改行・スペースのルール

演算子の前後

val result = a + b * c

• 二項演算子の前後にはスペースを入れる

関数引数が複数行になる場合

fun createUser(
    name: String,
    age: Int,
    email: String,
)

• Android公式では「1引数1行」の形を明確に定義
• Kotlin公式では「可読性を優先し、整形はツールに任せる」という立場

Android準拠かどうかで判断するのが安全です。

トレーリングカンマ（末尾カンマ）

data class User(
    val id: Int,
    val name: String,
)

• Kotlin公式では optional（必須ではない）
• 宣言側（class / function / enum 定義）では推奨
• 呼び出し側（call site）は任意

差分が見やすくなるため、宣言側では多くの現場で採用されています。

Null安全の扱い

非nullを基本にする

val name: String = "Alice"

• String? は「nullが意味を持つ場合のみ」

!! は極力使わない

// 非推奨
val length = name!!.length

// 推奨
val length = name?.length ?: 0

• !! は最後の手段
• 出てきたら設計を見直すサインと考える

val と var の使い分け

val userId = 10
var score = 0

• 基本は val
• 再代入が必要な場合のみ var
• Kotlin公式でも不変性（Immutability）が強く推奨されている

関数設計の考え方

単一責任を守る

// 悪い例
fun processUser() {
    validate()
    save()
    notifyUser()
}

// 良い例
fun validateUser()
fun saveUser()
fun notifyUser()

Expression body の利用

fun max(a: Int, b: Int): Int =
    if (a > b) a else b

• 単一式なら = を使ってよい
• 可読性が下がる場合は無理に使わない

クラス設計・data class

data class User(
    val id: Int,
    val name: String,
)

• DTO / Entity には data class を使うのが一般的
• equals / hashCode / toString を自動生成

可視性修飾子

private fun internalLogic()
internal class InternalService

• 可能な限りスコープを狭く
• public は慎重に公開する

コレクション操作とループ

users
    .filter { it.isActive }
    .map { it.name }

• 宣言的で意図が分かりやすい
• ただしチェーンが深くなりすぎないよう注意

公式の注意点

• Kotlin公式では forEach は例外的な位置づけ
• 単純なループでは for の方が好ましい場合が多い

コメント・KDoc

/**
 * ユーザーを取得する
 *
 * @param id ユーザーID
 * @return ユーザー情報
 */
fun getUser(id: Int): User

• ライブラリ開発では、公開APIにKDocを付けることが公式に推奨されている
• アプリ内コードでは、
  • 公開API
  • 複雑なロジック
  • 意図が伝わりにくい処理
    に限定して付けるのが一般的

実務ベストプラクティス（公式規約ではない）

以下は Kotlin公式に明文化されている規約ではありませんが、
多くの現場で採用されています。

• 拡張関数は意味が明確な場合のみ使う
• トップレベル関数は乱用しない
• ファイルは1責務を意識する
• ファイル名は内容が分かるものにする

フォーマッタ・Lintの利用（必須）

• ktlint
• detekt
• IDEの自動整形（Ctrl + Alt + L / ⌘ + ⌥ + L）

Kotlin開発では「人が規約を覚える」のではなく「ツールに守らせる」という考え方が前提です。

以上、Kotlinのコーディング規約についてでした。

最後までお読みいただき、ありがとうございました。