Kotlin コーディング規約

Kotlin

概要

Kotlin コーディング規約から個人的に忘れそうな部分を抜き出した備忘録です。 ここに記載されている以外の内容も有益なので原文の参照をおすすめします。

目次

参考情報

備忘録

Source code organization

Source file organization

複数の宣言を同じ1つのファイルに配置することは、以下の条件を全て満たす場合のみ推奨されます。宣言には、classes, top-level functions, top-level properties などが該当します。

  • これらの宣言が意味的に密接に関連している
  • ファイルサイズが妥当な範囲内(数百行を超えない)

Class layout

  1. Property declarations and initializer blocks
  2. Secondary constructors
  3. Method declarations
  4. Companion object

以下を行ってはいけません。

  • メソッドをアルファベット順に並べる
  • メソッドを可視性で並べる
  • 通常のメソッドと拡張メソッドを分離する

nested classes はそのクラスを使用するコードの次に置きます。nested classes が外部で使用されることを意図している場合は companion object の後に置きます。

Naming rules

package の命名では小文字のみを使用し _ は使用しません。複数語から成る名前は通常は推奨されませんが、使用する必要がある場合は単語を連結する (nameexample) か camel case (nameExample) を使用します。

Function names

クラスのインスタンスを生成する factory functions の場合は戻り値の型と同じ名前を使用します。例えば、戻り値の型が Foo の場合は fun Foo(): Foo { ... } とします。

Property names

以下の val properties には大文字を _ で接続した名前 (EXAMPLE_NAME) を使用します。

  • const が付けられている
  • top-level か object で、カスタムの get function を持たず、変更不可能なデータを保持している

シングルトンオブジェクトへの参照を持つ properties には object 宣言と同じ規則で名前を付けます。つまり、クラスと同様の名前を付けます。

enum constants は以下のいずれかの名前を使います。

  • uppercase underscore-separated names (例えば、RED, BLUE, GREEN)
  • upper camel case names (例えば、Red, Blue, Green)

Names for backing properties

プレフィックスに _ を付けます。

Choose good names

名前の一部に頭文字を使用している場合は以下の規則に従います。

  • 2文字の場合は全て大文字 (例えば、IOStream であり IoStream ではない)
  • 3文字以上の場合は先頭のみ大文字 (例えば、HttpInputStream であり HTTPInputStream ではない)

Formatting

Horizontal whitespace

// の後には空白を入れること。

水平方向で揃えることは避けること。識別子の名前の長さが変わった場合に影響を受けるべきではありません。

Colon

以下の場合は : の前に空白を入れます。

  • type と super type を分ける (例えば、class FooImpl : Foo())
  • 他の constructor に委譲する (例えば、constructor(x: Int) : this(x))
  • object キーワードの後 (例えば、object : IFoo)

Class headers

長いため省略。原文を参照のこと。

Modifiers order

長いため省略。原文を参照のこと。

Annotations

引数ありの注釈を複数並べるときは改行します。引数なし注釈を複数並べるときは1行に並べます。引数なし注釈が1つの場合は宣言と同じ行に書きます。

File annotations

ファイルコメントの後、package 宣言の前に書きます。但し、package 宣言との間に空行を入れ、package ではなくファイルに対する注釈であることを強調します。

Lambdas

パラメーターリストが長すぎて1行に収まらない場合は、-> を別の行に配置します。

Trailing commas

Kotlin スタイルガイドでは宣言時の引数末尾へのコンマ記載を推奨しています。

Documentation comments

通常は @param や @return などのタグの使用は避けます。文中に [paramName] と記載します。

Avoid redundant constructs

「わかりやすくするため」だけに不要な構文要素をコードに残さない様にします。例えば、戻り値の型の Unit、セミコロン、string template 中の {} などは不要な場合にはなくします。

Idiomatic use of language features

Lambda parameters

短く、ネストされていないラムダでは、it の使用を推奨します。

Named arguments

以下の場合には named argument の使用を推奨します。

  • 同一の基本型を複数とる
  • Boolean 型 (全ての引数が文脈より絶対的に明確である場合を除き)

Nullable Boolean values in conditions

nullable Boolean の比較は value == true と value == false で比較する。

Loops

基本的には通常の for ループの使用を推奨します。但し、以下の場合は forEach 関数を使用します。

  • forEach のレシーバーが nullable
  • 長い call chain の一部として使う

Functions vs properties

以下の場合は functions より properties を優先して使用します。

  • 例外を投げない
  • 計算が安価、もしくは、一度だけ計算してキャッシュしている
  • オブジェクトの状態が変更されない限り、呼び出しの度に同じ結果を返す