17/06/2021 Coding conventions | Kotlin

Regardez l'enregistrement de l'événement Kotlin 1.5 !

v1.5.10 Solutions Documents Communauté Apprendre Jouer

Conventions de codage
Modifier la page Dernière modification : 15 juin 2021

Les conventions de codage connues et faciles à suivre sont vitales pour tout langage de
programmation. Ici, nous fournissons des directives sur le style de code et l'organisation du code pour
les projets qui utilisent Kotlin.

Configurer le style dans l'IDE

Deux IDE les plus populaires pour Kotlin - IntelliJ IDEA ↗ et Android Studio ↗ offrent une prise en
charge puissante du style de code. Vous pouvez les configurer pour formater automatiquement votre
code en cohérence avec le style de code donné.

Appliquer la charte graphique

1. Allez dans Paramètres | Éditeur | Style de code | Kotlin .

2. Cliquez sur Définir à partir de... .

3. Sélectionnez le guide de style Kotlin .

Vérifiez que votre code suit le guide de style

1. Allez dans Paramètres | Éditeur | Contrôles | Kotlin .

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 1/29
17/06/2021 Coding conventions | Kotlin

2. Ouvrir Kotlin | Problèmes de style .

3. Activer Le fichier n'est pas formaté conformément à l' inspection des paramètres du projet . Des
inspections supplémentaires qui vérifient d'autres problèmes décrits dans le guide de style (comme
les conventions de dénomination) sont activées par défaut.

Organisation du code source

Structure du répertoire
Dans les projets Kotlin purs, la structure de répertoire recommandée suit la structure du package avec
le package racine commun omis. Par exemple, si tout le code du projet se trouve dans le
org.example.kotlin package et ses sous-packages, les fichiers avec le org.example.kotlin
package doivent être placés directement sous la racine source et les fichiers
org.example.kotlin.network.socket doivent être dans le network/socket sous - répertoire de
la racine source.

Sur JVM : dans les projets où Kotlin est utilisé avec Java, les fichiers source de Kotlin doivent
résider dans la même racine source que les fichiers source Java et suivre la même structure
de répertoire : chaque fichier doit être stocké dans le répertoire correspondant à chaque
instruction de package.

Noms des fichiers sources

Si un fichier Kotlin contient une seule classe (potentiellement avec des déclarations de niveau supérieur
associées), son nom doit être le même que le nom de la classe, avec l' .kt extension ajoutée. Si un
fichier contient plusieurs classes ou uniquement des déclarations de niveau supérieur, choisissez un
nom décrivant ce que contient le fichier et nommez le fichier en conséquence. Utilisez la casse camel
majuscule ↗ avec une première lettre majuscule (également connue sous le nom de casse Pascal), par
exemple, ProcessDeclarations.kt .

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 2/29
17/06/2021 Coding conventions | Kotlin

Le nom du fichier doit décrire ce que fait le code dans le fichier. Par conséquent, vous devez éviter
d'utiliser des mots dénués de sens comme Util dans les noms de fichiers.

Organisation du fichier source

Placer plusieurs déclarations (classes, fonctions ou propriétés de niveau supérieur) dans le même fichier
source Kotlin est encouragé tant que ces déclarations sont étroitement liées sémantiquement et que la
taille du fichier reste raisonnable (ne dépassant pas quelques centaines de lignes).

En particulier, lors de la définition de fonctions d'extension pour une classe qui sont pertinentes pour
tous les clients de cette classe, placez-les dans le même fichier avec la classe elle-même. Lorsque vous
définissez des fonctions d'extension qui n'ont de sens que pour un client spécifique, placez-les à côté
du code de ce client. Évitez de créer des fichiers uniquement pour contenir toutes les extensions d'une
classe.

Disposition de la classe
Le contenu d'une classe doit aller dans l'ordre suivant :

1. Déclarations de propriétés et blocs d'initialisation

2. Constructeurs secondaires

3. Déclarations de méthode

4. Objet compagnon

Ne triez pas les déclarations de méthode par ordre alphabétique ou par visibilité, et ne séparez pas les
méthodes normales des méthodes d'extension. Au lieu de cela, rassemblez des éléments connexes, de
sorte que quelqu'un qui lit le cours de haut en bas puisse suivre la logique de ce qui se passe.
Choisissez un ordre (soit des trucs de niveau supérieur en premier, soit vice versa) et respectez-le.

Placez les classes imbriquées à côté du code qui utilise ces classes. Si les classes sont destinées à être
utilisées en externe et ne sont pas référencées à l'intérieur de la classe, placez-les à la fin, après l'objet
compagnon.
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 3/29
17/06/2021 Coding conventions | Kotlin

Disposition d'implémentation d'interface

Lors de l'implémentation d'une interface, gardez les membres d'implémentation dans le même ordre
que les membres de l'interface (si nécessaire, entrecoupés de méthodes privées supplémentaires
utilisées pour l'implémentation).

Disposition de surcharge
Mettez toujours les surcharges les unes à côté des autres dans une classe.

Règles de nommage
Les règles de nommage des packages et des classes dans Kotlin sont assez simples :

• Les noms de packages sont toujours en minuscules et n'utilisent pas de traits de soulignement (
org.example.project ). L'utilisation de noms à plusieurs mots est généralement déconseillée,
mais si vous avez besoin d'utiliser plusieurs mots, vous pouvez soit les concaténer ensemble, soit
utiliser la casse camel ( org.example.myProject ).

• Les noms de classes et d'objets commencent par une lettre majuscule et utilisent la casse camel :

open class DeclarationProcessor { /*...*/ }

object EmptyDeclarationProcessor : DeclarationProcessor() { /*...*/ }

Noms de fonction
Les noms de fonctions, propriétés et variables locales commencent par une lettre minuscule et utilisent
la casse camel et aucun trait de soulignement :

fun processDeclarations() { /*...*/ }

var declarationCount = 1
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 4/29
17/06/2021 Coding conventions | Kotlin

Exception : les fonctions d'usine utilisées pour créer des instances de classes peuvent avoir le même
nom que le type de retour abstrait :

interface Foo { /*...*/ }

class FooImpl : Foo { /*...*/ }

fun Foo(): Foo { return FooImpl() }

Noms des méthodes d'essai

Dans les tests (et uniquement dans les tests), vous pouvez utiliser des noms de méthode avec des
espaces entourés de backticks. Notez que ces noms de méthode ne sont actuellement pas pris en
charge par l'environnement d'exécution Android. Les traits de soulignement dans les noms de méthode
sont également autorisés dans le code de test.

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

@Test fun ensureEverythingWorks_onAndroid() { /*...*/ }

}

Noms des propriétés

Les noms de constantes (propriétés marquées par const , ou val propriétés de niveau supérieur ou
d'objet sans get fonction personnalisée qui contiennent des données profondément immuables)
doivent utiliser des noms séparés par des traits de soulignement en majuscules ( serpent hurlant ↗ ) :

const val MAX_COUNT = 8

val USER_NAME_FIELD = "UserName"

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 5/29
17/06/2021 Coding conventions | Kotlin

Les noms de propriétés de niveau supérieur ou d'objet qui contiennent des objets avec un
comportement ou des données mutables doivent utiliser des noms de cas de chameau :

val mutableCollection: MutableSet<String> = HashSet()

Les noms de propriétés contenant des références à des objets singleton peuvent utiliser le même style
de dénomination que les object déclarations :

val PersonComparator: Comparator<Person> = /*...*/

Pour les constantes d'énumération, il est possible d'utiliser des noms séparés par des traits de
soulignement en majuscules ( crier la casse du serpent ↗ ) ( enum class Color { RED, GREEN } )
ou des noms en majuscule en majuscule, selon l'utilisation.

Noms des propriétés de support

Si une classe a deux propriétés conceptuellement identiques mais que l'une fait partie d'une API
publique et l'autre est un détail d'implémentation, utilisez un trait de soulignement comme préfixe pour
le nom de la propriété privée :

class C {
private val _elementList = mutableListOf<Element>()

val elementList: List<Element>

get() = _elementList
}

Choisissez les bons noms

Le nom d'une classe est généralement un nom ou une phrase nom expliquant ce que la classe est :
List , PersonReader .

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 6/29
17/06/2021 Coding conventions | Kotlin

Le nom d'une méthode est généralement un verbe ou une phrase verbe dire ce que la méthode fait :
close , readPersons . Le nom doit également suggérer si la méthode mute l'objet ou en renvoie un
nouveau. Par exemple, sort trie une collection en place, tandis que sorted renvoie une copie triée
de la collection.

Les noms doivent indiquer clairement quel est le but de l'entité, il est donc préférable d'éviter d'utiliser
des mots dénués de sens ( Manager , Wrapper ) dans les noms.

Lorsque vous utilisez un acronyme dans le cadre d'un nom de déclaration, mettez-le en majuscule s'il se
compose de deux lettres ( IOStream ) ; mettre en majuscule uniquement la première lettre si elle est
plus longue ( XmlFormatter , HttpInputStream ).

Mise en page
Échancrure
Utilisez quatre espaces pour l'indentation. N'utilisez pas d'onglets.

Pour les accolades, placez l'accolade ouvrante à la fin de la ligne où commence la construction et
l'accolade fermante sur une ligne distincte alignée horizontalement avec la construction ouvrante.

if (elements != null) {
for (element in elements) {
// ...
}
}

Dans Kotlin, les points-virgules sont facultatifs et les sauts de ligne sont donc importants. La
conception du langage suppose des accolades de style Java et vous pouvez rencontrer un
comportement surprenant si vous essayez d'utiliser un style de formatage différent.

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 7/29
17/06/2021 Coding conventions | Kotlin

Espace horizontal
• Mettez des espaces autour des opérateurs binaires ( a + b ). Exception : ne placez pas d'espaces
autour de l'opérateur "plage jusqu'à" ( 0..i ).

• Ne placez pas d'espaces autour des opérateurs unaires ( a++ ).

• Placez des espaces entre les mots-clés du flux de contrôle ( if , when , for , et while ) et la
parenthèse ouvrante correspondante.

• Ne placez pas d'espace avant une parenthèse ouvrante dans une déclaration de constructeur
primaire, une déclaration de méthode ou un appel de méthode.

class A(val x: Int)

fun foo(x: Int) { ... }

fun bar() {
foo(1)
}

• Ne jamais mettre un espace après ( , [ ou avant ] , )

• Ne jamais mettre d'espace autour . ou ?. : foo.bar().filter { it > 2 }.joinToString()

, foo?.bar()

• Mettez un espace après // : // This is a comment

• Ne placez pas d'espaces autour des chevrons utilisés pour spécifier les paramètres de type :
class Map<K, V> { ... }

• Ne pas mettre d'espaces autour :: : Foo::class , String::length

• Ne mettez pas d'espace avant d' ? utiliser pour marquer un type nullable : String?

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 8/29
17/06/2021 Coding conventions | Kotlin

En règle générale, évitez les alignements horizontaux de quelque nature que ce soit. Renommer un
identifiant en un nom de longueur différente ne devrait pas affecter le formatage de la déclaration ou
de l'un des usages.

Côlon
Mettez un espace avant : dans les cas suivants :

• quand il est utilisé pour séparer un type et un supertype

• lors de la délégation à un constructeur de superclasse ou à un constructeur différent de la même

classe

• après le object mot - clé

Ne mettez pas d'espace avant : lorsqu'il sépare une déclaration et son type.

Mettez toujours un espace après : .

abstract class Foo<out T : Any> : IFoo {

abstract fun foo(a: Int): T
}

class FooImpl : Foo() {

constructor(x: String) : this(x) { /*...*/ }

val x = object : IFoo { /*...*/ }

}

En-têtes de classe
Les classes avec quelques paramètres de constructeur primaire peuvent être écrites sur une seule ligne :

class Person(id: Int, name: String)

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 9/29
17/06/2021 Coding conventions | Kotlin

class Person(id: Int, name: String)

Les classes avec des en-têtes plus longs doivent être formatées de sorte que chaque paramètre de
constructeur principal se trouve sur une ligne distincte avec une indentation. De plus, la parenthèse
fermante doit être sur une nouvelle ligne. Si vous utilisez l'héritage, l'appel du constructeur de la
superclasse ou la liste des interfaces implémentées doit se trouver sur la même ligne que la
parenthèse :

class Person(
id: Int,
name: String,
surname: String
) : Human(id, name) { /*...*/ }

Pour plusieurs interfaces, l'appel du constructeur de superclasse doit être situé en premier, puis chaque
interface doit être située sur une ligne différente :

class Person(
id: Int,
name: String,
surname: String
) : Human(id, name),
KotlinMaker { /*...*/ }

Pour les classes avec une longue liste de supertypes, placez un saut de ligne après les deux points et
alignez tous les noms de supertypes horizontalement :

class MyFavouriteVeryLongClassHolder :
MyLongHolder<MyFavouriteVeryLongClass>(),
SomeOtherInterface,
AndAnotherOne {

fun foo() { /*...*/ }

}

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 10/29
17/06/2021 Coding conventions | Kotlin

Pour séparer clairement l'en-tête de classe et le corps lorsque l'en-tête de classe est long, placez une
ligne vide après l'en-tête de classe (comme dans l'exemple ci-dessus), ou placez l'accolade ouvrante sur
une ligne distincte :

class MyFavouriteVeryLongClassHolder :
MyLongHolder<MyFavouriteVeryLongClass>(),
SomeOtherInterface,
AndAnotherOne
{
fun foo() { /*...*/ }
}

Utilisez un retrait régulier (quatre espaces) pour les paramètres du constructeur. Cela garantit que les
propriétés déclarées dans le constructeur principal ont la même indentation que les propriétés
déclarées dans le corps d'une classe.

Ordre des modificateurs

Si une déclaration a plusieurs modificateurs, placez-les toujours dans l'ordre suivant :

public / protected / private / internal

expect / actual
final / open / abstract / sealed / const
external
override
lateinit
tailrec
vararg
suspend
inner
enum / annotation / fun // as a modifier in `fun interface`
companion
inline / value
infix

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 11/29
17/06/2021 Coding conventions | Kotlin

operator
data

Placez toutes les annotations avant les modificateurs :

@Named("Foo")
private val foo: Foo

À moins que vous ne travailliez sur une bibliothèque, omettez les modificateurs redondants (par
exemple, public ).

Annotations
Placez les annotations sur des lignes distinctes avant la déclaration à laquelle elles sont attachées, et
avec la même indentation :

@Target(AnnotationTarget.PROPERTY)
annotation class JsonExclude

Les annotations sans arguments peuvent être placées sur la même ligne :

@JsonExclude @JvmField
var x: String

Une seule annotation sans arguments peut être placée sur la même ligne que la déclaration
correspondante :

@Test fun foo() { /*...*/ }

Annotations de fichiers
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 12/29
17/06/2021 Coding conventions | Kotlin

Les annotations de fichier sont placées après le commentaire de fichier (le cas échéant), avant l'
package instruction, et sont séparées package par une ligne vide (pour souligner le fait qu'elles
ciblent le fichier et non le package).

/** License, copyright and whatever */

@file:JvmName("FooBar")

package foo.bar

Les fonctions
Si la signature de la fonction ne tient pas sur une seule ligne, utilisez la syntaxe suivante :

fun longMethodName(
argument: ArgumentType = defaultValue,
argument2: AnotherArgumentType,
): ReturnType {
// body
}

Utilisez un retrait régulier (quatre espaces) pour les paramètres de fonction. Cela permet d'assurer la
cohérence avec les paramètres du constructeur.

Préférez utiliser un corps d'expression pour les fonctions dont le corps consiste en une seule
expression.

fun foo(): Int { // bad

return 1
}

fun foo() = 1 // good

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 13/29
17/06/2021 Coding conventions | Kotlin

Corps d'expression
Si la fonction a un corps d'expression dont la première ligne ne tient pas sur la même ligne que la
déclaration, placez le = signe sur la première ligne et indentez le corps de l'expression de quatre
espaces.

fun f(x: String, y: String, z: String) =

veryLongFunctionCallWithManyWords(andLongParametersToo(), x, y, z)

Propriétés
Pour des propriétés en lecture seule très simples, envisagez une mise en forme sur une ligne :

val isEmpty: Boolean get() = size == 0

Pour les propriétés plus complexes, placez toujours get et les set mots - clés sur des lignes
séparées :

val foo: String

get() { /*...*/ }

Pour les propriétés avec un initialiseur, si l'initialiseur est long, ajoutez un saut de ligne après le = signe
et indentez l'initialiseur de quatre espaces :

private val defaultCharset: Charset? =

EncodingRegistry.getInstance().getDefaultCharsetForPropertiesFiles(fi

Instructions de flux de contrôle

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 14/29
17/06/2021 Coding conventions | Kotlin

Si la condition d'une instruction if ou when est multiligne, utilisez toujours des accolades autour du
corps de l'instruction. Indenter chaque ligne suivante de la condition de quatre espaces par rapport au
début de l'instruction. Placez les parenthèses fermantes de la condition avec l'accolade ouvrante sur
une ligne distincte :

if (!component.isSyncing &&
!hasAnyKotlinRuntimeInScope(module)
) {
return createKotlinNotConfiguredPanel(module)
}

Cela permet d'aligner les corps de la condition et de l'instruction.

Mettez les else , catch , finally mots - clés, ainsi que le while mot - clé d'une do-while
boucle, sur la même ligne que l'accolade précédente:

if (condition) {
// body
} else {
// else part
}

try {
// body
} finally {
// cleanup
}

Dans une when instruction, si une branche comporte plus d'une seule ligne, envisagez de la séparer
des blocs de cas adjacents par une ligne vide :

private fun parsePropertyValue(propName: String, token: Token) {

when (token) {
is Token.ValueToken ->
callback.visitValue(propName, token.value)
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 15/29
17/06/2021 Coding conventions | Kotlin

Token.LBRACE -> { // ...

}
}
}

Mettez des branches courtes sur la même ligne que la condition, sans accolades.

when (foo) {
true -> bar() // good
false -> { baz() } // bad
}

Appels de méthode
Dans les longues listes d'arguments, placez un saut de ligne après la parenthèse ouvrante. Indenter les
arguments de quatre espaces. Regroupez plusieurs arguments étroitement liés sur la même ligne.

drawSquare(
x = 10, y = 10,
width = 100, height = 100,
fill = true
)

Mettez des espaces autour du = signe séparant le nom et la valeur de l'argument.

Wrap des appels enchaînés

Lors de l'encapsulation d'appels chaînés, placez le . caractère ou l' ?. opérateur sur la ligne suivante,
avec un seul retrait :

val anchor = owner

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 16/29
17/06/2021 Coding conventions | Kotlin

a a c o o e
?.firstChild!!
.siblings(forward = true)
.dropWhile { it is PsiComment || it is PsiWhiteSpace }

Le premier appel de la chaîne devrait généralement être précédé d'un saut de ligne, mais vous pouvez
l'omettre si le code a plus de sens de cette façon.

Lambda
Dans les expressions lambda, des espaces doivent être utilisés autour des accolades, ainsi qu'autour de
la flèche qui sépare les paramètres du corps. Si un appel prend un seul lambda, passez-le en dehors des
parenthèses dans la mesure du possible.

list.filter { it > 10 }

Si vous attribuez une étiquette à un lambda, ne mettez pas d'espace entre l'étiquette et l'accolade
ouvrante :

fun foo() {
ints.forEach lit@{
// ...
}
}

Lors de la déclaration des noms de paramètres dans un lambda multiligne, placez les noms sur la
première ligne, suivis de la flèche et de la nouvelle ligne :

appendCommaSeparated(properties) { prop ->

val propertyValue = prop.get(obj) // ...
}

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 17/29
17/06/2021 Coding conventions | Kotlin

Si la liste des paramètres est trop longue pour tenir sur une ligne, placez la flèche sur une ligne
distincte :

foo {
context: Context,
environment: Env
->
context.configureEnv(environment)
}

Virgules de fin
Une virgule de fin est un symbole de virgule après le dernier élément d'une série d'éléments :

class Person(
val firstName: String,
val lastName: String,
val age: Int, // trailing comma
)

L'utilisation de virgules de fin présente plusieurs avantages :

• Cela rend les différences de contrôle de version plus propres, car tout l'accent est mis sur la valeur
modifiée.

• Cela facilite l'ajout et la réorganisation des éléments - il n'est pas nécessaire d'ajouter ou de
supprimer la virgule si vous manipulez des éléments.

• Il simplifie la génération de code, par exemple, pour les initialiseurs d'objets. Le dernier élément
peut également avoir une virgule.

Les virgules de fin sont entièrement facultatives - votre code fonctionnera toujours sans elles. Le guide
de style Kotlin encourage l'utilisation de virgules de fin sur le site de déclaration et le laisse à votre
discrétion pour le site d'appel.

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 18/29
17/06/2021 Coding conventions | Kotlin

Pour activer les virgules de fin dans le formateur IntelliJ IDEA, accédez à Paramètres | Éditeur | Style
de code | Kotlin , ouvrez l' onglet Autre et sélectionnez l' option Utiliser la virgule de fin .

Énumérations
Arguments de valeur
Propriétés et paramètres de classe
Paramètres de valeur de fonction
Paramètres avec type optionnel (y compris les setters)
Suffixe d'indexation
Paramètres en lambdas
lors de l'entrée
Littéraux de collection (dans les annotations)
Tapez les arguments
Paramètres de type
Déclarations déstructurantes

Commentaires sur la documentation

Pour des commentaires de documentation plus longs, placez l'ouverture /** sur une ligne distincte et
commencez chaque ligne suivante par un astérisque :

/**
* This is a documentation comment

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 19/29
17/06/2021 Coding conventions | Kotlin

* on multiple lines.
*/

Les commentaires courts peuvent être placés sur une seule ligne :

/** This is a short documentation comment. */

En règle générale, évitez d'utiliser @param et les @return balises. Au lieu de cela, incorporez la
description des paramètres et des valeurs de retour directement dans le commentaire de la
documentation, et ajoutez des liens vers les paramètres partout où ils sont mentionnés. Utilisation
@param et @return uniquement lorsqu'une longue description est nécessaire , ce qui ne rentre pas
dans le flux du texte principal.

// Avoid doing this:

/**
* Returns the absolute value of the given number.
* @param number The number to return the absolute value for.
* @return The absolute value.
*/
fun abs(number: Int) { /*...*/ }

// Do this instead:

/**
* Returns the absolute value of the given [number].
*/
fun abs(number: Int) { /*...*/ }

Éviter les constructions redondantes

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 20/29
17/06/2021 Coding conventions | Kotlin

En général, si une certaine construction syntaxique dans Kotlin est facultative et mise en évidence par
l'EDI comme redondante, vous devez l'omettre dans votre code. Ne laissez pas d'éléments syntaxiques
inutiles dans le code juste "pour plus de clarté".

Type de retour d'unité

Si une fonction renvoie Unit, le type de retour doit être omis :

fun foo() { // ": Unit" is omitted here

Points-virgules
Omettez les points-virgules dans la mesure du possible.

Modèles de chaîne
N'utilisez pas d'accolades lors de l'insertion d'une variable simple dans un modèle de chaîne. Utilisez
des accolades uniquement pour les expressions plus longues.

println("$name has ${children.size} children")

Utilisation idiomatique des caractéristiques

linguistiques
Immutabilité
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 21/29
17/06/2021 Coding conventions | Kotlin

Préférez utiliser des données immuables à mutables. Toujours déclarer les variables locales et les
propriétés que val plutôt que var si elles ne sont pas modifiés après l' initialisation.

Utilisez toujours des interfaces de collection immuables ( Collection , List , Set , Map ) pour
déclarer des collections qui ne sont pas mutées. Lorsque vous utilisez des fonctions d'usine pour créer
des instances de collection, utilisez toujours des fonctions qui renvoient des types de collection
immuables lorsque cela est possible :

// Bad: use of mutable collection type for value which will not be mutate
fun validateValue(actualValue: String, allowedValues: HashSet<String>) {

// Good: immutable collection type used instead

fun validateValue(actualValue: String, allowedValues: Set<String>) { ...

// Bad: arrayListOf() returns ArrayList<T>, which is a mutable collection

val allowedValues = arrayListOf("a", "b", "c")

// Good: listOf() returns List<T>

val allowedValues = listOf("a", "b", "c")

Valeurs des paramètres par défaut

Préférez déclarer des fonctions avec des valeurs de paramètre par défaut à déclarer des fonctions
surchargées.

// Bad
fun foo() = foo("a")
fun foo(a: String) { /*...*/ }

// Good
fun foo(a: String = "a") { /*...*/ }

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 22/29
17/06/2021 Coding conventions | Kotlin

Type d'alias
Si vous avez un type fonctionnel ou un type avec des paramètres de type qui est utilisé plusieurs fois
dans une base de code, préférez lui définir un alias de type :

typealias MouseClickHandler = (Any, MouseEvent) -> Unit

typealias PersonIndex = Map<String, Person>

Si vous utilisez un alias de type privé ou interne pour éviter les collisions de noms, préférez celui
import … as … mentionné dans Packages and Imports .

Paramètres lambda
Dans les lambdas courts et non imbriqués, il est recommandé d'utiliser la it convention au lieu de
déclarer le paramètre explicitement. Dans les lambdas imbriqués avec paramètres, déclarez toujours les
paramètres explicitement.

Retours dans un lambda

Évitez d'utiliser plusieurs retours étiquetés dans un lambda. Envisagez de restructurer le lambda afin
qu'il n'ait qu'un seul point de sortie. Si ce n'est pas possible ou pas assez clair, envisagez de convertir le
lambda en une fonction anonyme.

N'utilisez pas de retour étiqueté pour la dernière instruction dans un lambda.

Arguments nommés
Utilisez la syntaxe d'argument nommé lorsqu'une méthode prend plusieurs paramètres du même type
primitif, ou pour des paramètres de Boolean type, à moins que la signification de tous les paramètres
ne soit absolument claire du contexte.

drawSquare(x = 10, y = 10, width = 100, height = 100, fill = true)

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 23/29
17/06/2021 Coding conventions | Kotlin

Expressions conditionnelles
Préférez utiliser la forme d'expression de try , if , et when .

return if (x) foo() else bar()

return when(x) {
0 -> "zero"
else -> "nonzero"
}

Ce qui précède est préférable à :

if (x)
return foo()
else
return bar()

when(x) {
0 -> return "zero"
else -> return "nonzero"
}

si contre quand
Préférez utiliser if pour les conditions binaires au lieu de when . Par exemple, utilisez cette syntaxe
avec if :

if (x == null) ... else ...

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 24/29
17/06/2021 Coding conventions | Kotlin

au lieu de celui-ci avec when :

when (x) {
null -> // ...
else -> // ...
}

Préférez utiliser when s'il y a trois options ou plus.

Valeurs booléennes Nullable dans les conditions

Si vous devez utiliser un nullable Boolean dans une instruction conditionnelle, utilisez
if (value == true) ou if (value == false) vérifie.

Boucles
Préférez utiliser des fonctions d'ordre supérieur ( filter , map etc.) aux boucles. Exception :
forEach (préférez utiliser une for boucle normale à la place, sauf si le récepteur de forEach est
nullable ou forEach est utilisé dans le cadre d'une chaîne d'appel plus longue).

Lorsque vous choisissez entre une expression complexe utilisant plusieurs fonctions d'ordre supérieur
et une boucle, comprenez le coût des opérations effectuées dans chaque cas et gardez à l'esprit les
considérations de performances.

Boucles sur les plages

Utilisez la until fonction pour boucler sur une plage ouverte :

for (i in 0..n - 1) { /*...*/ } // bad

for (i in 0 until n) { /*...*/ } // good

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 25/29
17/06/2021 Coding conventions | Kotlin

Cordes
Préférez les modèles de chaînes à la concaténation de chaînes.

Prefer multiline strings to embedding \n escape sequences into regular string literals.

To maintain indentation in multiline strings, use trimIndent when the resulting string does not
require any internal indentation, or trimMargin when internal indentation is required:

println("""
Not
trimmed
text
"""
)

println("""
Trimmed
text
""".trimIndent()
)

println()

val a = """Trimmed to margin text:

|if(a > 1) {
| return a
|}""".trimMargin()

println(a)

Target platform: JVM Running on kotlin v.1.5.0

Learn the difference between Java and Kotlin multiline strings.

Functions vs properties
https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 26/29
17/06/2021 Coding conventions | Kotlin

In some cases functions with no arguments might be interchangeable with read-only properties.
Although the semantics are similar, there are some stylistic conventions on when to prefer one to
another.

Prefer a property over a function when the underlying algorithm:

• does not throw

• is cheap to calculate (or cached on the first run)

• returns the same result over invocations if the object state hasn't changed

Extension functions
Utilisez généreusement les fonctions d'extension. Chaque fois que vous avez une fonction qui
fonctionne principalement sur un objet, envisagez d'en faire une fonction d'extension acceptant cet
objet comme récepteur. Pour minimiser la pollution de l'API, restreignez la visibilité des fonctions
d'extension autant que cela a du sens. Si nécessaire, utilisez des fonctions d'extension locales, des
fonctions d'extension de membre ou des fonctions d'extension de niveau supérieur avec une visibilité
privée.

Fonctions infixes
Déclarez une fonction comme infix uniquement lorsqu'elle fonctionne sur deux objets qui jouent un
rôle similaire. Bons exemples : and , to , zip . Mauvais exemple : add .

Ne déclarez pas une méthode comme infix si elle mute l'objet récepteur.

Fonctions d'usine
Si vous déclarez une fonction d'usine pour une classe, évitez de lui donner le même nom que la classe
elle-même. Préférez utiliser un nom distinct pour indiquer clairement pourquoi le comportement de la

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 27/29
17/06/2021 Coding conventions | Kotlin

fonction d'usine est spécial. Seulement s'il n'y a pas vraiment de sémantique spéciale, vous pouvez
utiliser le même nom que la classe.

class Point(val x: Double, val y: Double) {

companion object {
fun fromPolar(angle: Double, radius: Double) = Point(...)
}
}

Si vous avez un objet avec plusieurs constructeurs surchargés qui n'appellent pas différents
constructeurs de superclasse et ne peuvent pas être réduits à un seul constructeur avec des valeurs
d'argument par défaut, préférez remplacer les constructeurs surchargés par des fonctions d'usine.

Types de plate-forme
Une fonction/méthode publique renvoyant une expression d'un type de plate-forme doit déclarer
explicitement son type Kotlin :

fun apiCall(): String = MyJavaApi.getProperty("name")

Toute propriété (au niveau du package ou au niveau de la classe) initialisée avec une expression d'un
type de plate-forme doit déclarer explicitement son type Kotlin :

class Person {
val name: String = MyJavaApi.getProperty("name")
}

Une valeur locale initialisée avec une expression d'un type de plate-forme peut avoir ou non une
déclaration de type :

fun main() {
val name = MyJavaApi.getProperty("name")

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 28/29
17/06/2021 Coding conventions | Kotlin

println(name)
}

Les fonctions de portée s'appliquent/avec/exécuter/

également/let
Kotlin fournit un ensemble de fonctions pour exécuter un bloc de code dans le contexte d'un objet
donné : let , run , with , apply , et also . Pour obtenir des conseils sur le choix de la fonction
d'étendue adaptée à votre cas, reportez-vous à Fonctions d'étendue .

Conventions de codage pour les

bibliothèques
Lors de l'écriture de bibliothèques, il est recommandé de suivre un ensemble de règles supplémentaires
pour garantir la stabilité de l'API :

• Spécifiez toujours explicitement la visibilité des membres (pour éviter d'exposer accidentellement
des déclarations en tant qu'API publique)

• Spécifiez toujours explicitement les types de retour de fonction et les types de propriété (pour éviter
de modifier accidentellement le type de retour lorsque l'implémentation change)

• Fournir des commentaires KDoc pour tous les membres publics, à l'exception des remplacements
qui ne nécessitent aucune nouvelle documentation (pour prendre en charge la génération de
documentation pour la bibliothèque)

https://kotlinlang.org/docs/coding-conventions.html#conditional-statements 29/29