kotlin小ネタ：code arrangement rule メモ

kotlin coding conventions

kotlin の code arrangement に関するおいらの独自ルールメモ。

IntelliJ IDEA の kotlin の rearrange code 機能については中の人が 2016-11-21付で以下のような回答をしてるので、実装は気長に待つのが良さそうですね。

stackoverflow.com

以下おいら独自ルール(とりあえずのやっつけザックリ版)

配置順は優先順位が同一の場合は基本的にスコープの広いもの順とアルファベット順。

interface の場合の配置順

  1. val(alphabetical order)
  2. var(alphabetical order)
  3. fun(alphabetical order)
  4. nested classes
  5. inner classes
  6. companion class

class の場合の配置順

  1. Arguments of primary constructor.(直観的にわかりやすい順番 *1 )
  2. Properties which have backing fields.*2
  3. init block*3
  4. Members(backing field への assignment のあるもの *4 )
  5. Members(backing field への assignment のないもの *5 )
  6. nested classes*6
  7. companion class
  8. object StaticFunctions*7

考察

  • functions と properties を混在させているのは、kotlin では property に手続きを記述することができ、これらと function を置き換えたくなることが多いため。下記のようなことが起こるたびにメンバの順番を入れ替えなきゃいけないというのはめんどい。
// 元のソース
fun getName(sessionId: Int): String

// sessionId が文脈から得られるようになったら以下のように変更可能
fun getName(): String

// それなら以下のようにしたい
val name: String

まだあまり深く考えていないので、既存の coding conventions を参考に練っていきましょうかね。

*1:直観的にわかりやすい順番というのはザックリ過ぎるのでもう少し厳格な基準を設けたほうがいい気がする。しかし alphabetical order は現実的じゃない(オプション的な boolean が先頭に来るとか varargs/default value との兼ね合いとか)。

*2:アルファベット順を強制するため、定義のみで値の初期化は行わない。var の override 時など定義時に初期化が必須の場合は null をセットしておく。

*3:backing field を持つ properties の初期化はここで行う

*4:assignment と backing field に格納されているオブジェクトの状態を変えることを混同しないように注意。

*5:StaticFunction の関数を1つ呼び出すだけ。

*6:まだ深く考えてない。

*7:参照透明性のある関数群