kotlin-style-guide
kotlin-style-guide copied to clipboard
Kotlin
Work-in-progress notes for the Kotlin style guide
When accessing a property multiple times which cannot be smart cast, i.e. is any of the following: - open - a `var` - does not have a backing field Prefer...
This issue lists references to coding conventions that were developed in production teams using Kotlin. - [Corda](https://www.corda.net/) (Mike Hearn) https://docs.corda.net/head/codestyle.html - [Blockchain](https://www.blockchain.com/) (Adam Bennett) https://github.com/ditn/KotlinStyleGuide - [Gridstone](https://gridstone.com.au/) (Chris Horner) https://github.com/Gridstone/KotlinStyleGuide...
Using loops
Prefer using higher-order functions (filter, map etc.) to loops. Exception: forEach (prefer using a regular for loop instead).
Using casts
Do not use free-standing `as` expressions for smart casts. Instead, assign a new name to the variable after the cast. Good: ``` fun foo(x: Any) { val s = x...
### if-else A one-line `if-else` expression should not use curly bracket blocks: ``` kotlin val max = if(a > b) a else b ``` A multiline `if-else` may not to...
Use the named argument syntax when a method takes multiple parameters of the same primitive type, or for parameters of `Boolean` type. ``` drawSquare(x = 10, y = 10, width...
Anyone looking for a solution **RIGHT NOW** this project exists: [Ktlint](https://github.com/shyiko/ktlint) Something that should be added to the readme perhaps?
Boolean parameters in a multi-parameter function (boolean flags) must be marked on a call site to clarify their meaning. In for Kotlin functions use named parameters. For Java functions use...
A public function/method returning an expression of a platform type must declare its kotlin type explicitly: ``` fun apiCall(): String = MyJavaApi.getProperty("name") ``` Any property (package-level or class-level) initialised with...
Functions should only be made `inline` when they use `inline`-only features like inlined lambda parameters or reified types. Inline functions should generally be short as they increase the code size...
