Directory structure

the recommended directory structure follows the package structure with the common root package omitted.


Source file names

Use upper camel case


If a Kotlin file contains a single class (potentially with related top-level declarations), its name should be the same as the name of the class


If a file contains multiple classes, or only top-level declarations, choose a name describing what the file contains

ファイルが複数のクラスを含む or トップレベル宣言で構成される場合は構成要素を表現した名前にしましょう

The name of the file should describe what the code in the file does. Therefore, you should avoid using meaningless words such as Util in file names.


Source file organization

Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged as long as these declarations are closely related to each other semantically


In particular, when defining extension functions for a class which are relevant for all clients of this class, put them in the same file with the class itself.


Class layout

The contents of a class should go in the following order:
Property declarations and initializer blocks
Secondary constructors
Method declarations
Companion object


  1. プロパティ宣言, init関数
  2. セカンダリコンストラクタ
  3. メソッド
  4. companion object

Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together


Interface implementation layout

When implementing an interface, keep the implementing members in the same order as members of the interface


Overload layout

Always put overloads next to each other in a class.


Package and class naming rules

Names of packages are always lowercase and do not use underscores. Using multi-word names is generally discouraged, but if you do need to use multiple words, you can either just concatenate them together or use camel case


Names of classes and objects start with an uppercase letter and use camel case:


Function names

Names of functions, properties and local variables start with a lowercase letter and use camel case and no underscores:


Exception: factory functions used to create instances of classes can have the same name as the abstract return type:


interface Hoge { /*...*/ }

class HogeImpl : Hoge { /*...*/ }

fun Hoge(): Hoge { return HogeImpl() }

Names for test methods

In tests (and only in tests), you can use method names with spaces enclosed in backticks.


@Test fun `ensure everything works`() { /*...*/ }

Property names

Names of constants (properties marked with const, or top-level or object val properties with no custom get function) should use uppercase underscore-separated

  • const 宣言
  • トップレベルに宣言されたvalプロパティ
  • objectのvalプロパティ(※但しカスタムgetterを持たないもの)


Names of top-level or object properties which hold objects with behavior or mutable data should use camel case names:


Names of properties holding references to singleton objects can use the same naming style as object declarations:


For enum constants, it's OK to use either uppercase underscore-separated names


Names for backing properties

use an underscore as the prefix for the name of the private property


class Person {
    private val _text: String = ""

    val text: String
        get() {
            return _text

Choose good names

The name of a class is usually a noun


The name of a method is usually a verb


The name should also suggest if the method is mutating the object or returning a new one


  • sort => 対象のインスタンスを直接ソートする
  • sorted => 対象のインスタンスをソートした新しいインスタンスが返る


Use four spaces for indentation. Do not use tabs.


put the opening brace in the end of the line where the construct begins

// OK
fun some() {

// NG
fun some()

Horizontal whitespace(※一部)

Put spaces between control flow keywords (if, when, for, and while)

if, when, for, whileの後はスペース入れなさい

Never put a space after (, [, or before ], )


Put a space after //: // This is a comment

// の後にはスペースを入れなさい