Help us understand the problem. What is going on with this article?

Kotlin コード規約( Source code organization )

More than 1 year has passed since last update.

公式の和訳(意訳)です.

ソースコード構成

ディレクトリ構造

複数の言語で構成されるプロジェクトの場合, Kotlin ファイルは Java ファイルと同じソースルートに置き,同じディレクトリ構成にする.
(Java と Kotlin それぞれのファイルは,パッケージ名に対応するディレクトリに置く).

Kotlin のみで構成されるプロジェクトの場合,共通のルートパッケージを省略したパッケージ構造に従ったディレクトリ構造を推奨する.
(たとえば,プロジェクトのすべてのコードが "org.example.kotlin" パッケージ以下にあるとき, "org.example.kotlin" パッケージのファイルははソースルートに置く.
また, "org.example.kotlin.foo.bar" のファイルはルート直下の "foo/bar" ディレクトリに置く).

ファイル名

Kotlin ファイルに単一のクラス(および,そのクラスに関連するトップレベル宣言)があるとき,ファイル名はクラス名に .kt 拡張子をつけたものになる.
ファイルに複数のクラスがあるか,トップレベル宣言しかないないとき,ファイル名はそのファイルの内容を表す名前にする.
ファイル名には,キャメルケースを用い,最初の文字は大文字にする( ProessDeclarations.kt など).

ファイル名は,中身のコードの処理を表す.
なので, "Util" のような無意味な単語を使うのは避けるべきである.

ファイル構造

意味的に強い関連があり,ファイルサイズも妥当である(数百行は続かない)ならば,同じファイル内にクラスやトップレベルの関数・プロパティのような宣言を複数書くことを推奨する.

特に,あるクラスのすべてのクライアントに関連する拡張関数を定義するときは,そのクラス自体が定義されているファイルに書く.
特定のクライアントに対してだけ意味がある拡張関数を定義するときは,そのクライアントの近くに書く.
"Foo クラスのすべての拡張関数" を羅列するためだけのファイルを作らない.

クラス内のコードの配置

一般に,クラス内のコードは以下の順序で書く.

  1. プロパティ宣言と初期化ブロック
  2. セカンダリコンストラクタ
  3. メソッド宣言
  4. コンパニオンオブジェクト

メソッド宣言をアルファベット順や可視性の順にソートしてはならない.
また,通常のメソッドと拡張関数を区別してはならない.
代わりに,関連するものをまとめて書く.
コードを読む人がそのクラスを上から順に読んだときに,何が起こっているかを理解できるようにするためだ.
高レベルのものから順に書くか,低レベルのものから順に書くか,適当に決めて一貫性を持たせる.

ネストされたクラスは,そのクラスを使用する場所の近くに書く.
もし,ネストされたクラスが外部で使用されることを意図したもので,内部からは参照されないのならば,コンパニオンオブジェクトの次,クラスの最後に書く.

インターフェースの実装の配置

インターフェースを実装するとき,メンバの実装はインターフェースでの宣言と同じ順にする.
(インターフェースの実装に private メソッドが必要な場合は,インターフェースの実装の間に書く).

演算子オーバーロードの配置

演算子オーバーロードは,常にクラス内の隣り合った場所に書く.

hmiyado
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away