forked from kscience/kmath
28 lines
1.6 KiB
Markdown
28 lines
1.6 KiB
Markdown
# Coding Conventions
|
|
|
|
Generally, KMath code follows general [Kotlin coding conventions](https://kotlinlang.org/docs/reference/coding-conventions.html), but with a number of small changes and clarifications.
|
|
|
|
## Utility Class Naming
|
|
|
|
Filename should coincide with a name of one of the classes contained in the file or start with small letter and describe its contents.
|
|
|
|
The code convention [here](https://kotlinlang.org/docs/reference/coding-conventions.html#source-file-names) says that file names should start with a capital letter even if file does not contain classes. Yet starting utility classes and aggregators with a small letter seems to be a good way to visually separate those files.
|
|
|
|
This convention could be changed in future in a non-breaking way.
|
|
|
|
## Private Variable Naming
|
|
|
|
Private variables' names may start with underscore `_` for of the private mutable variable is shadowed by the public read-only value with the same meaning.
|
|
|
|
This rule does not permit underscores in names, but it is sometimes useful to "underscore" the fact that public and private versions draw up the same entity. It is allowed only for private variables.
|
|
|
|
This convention could be changed in future in a non-breaking way.
|
|
|
|
## Functions and Properties One-liners
|
|
|
|
Use one-liners when they occupy single code window line both for functions and properties with getters like
|
|
`val b: String get() = "fff"`. The same should be performed with multiline expressions when they could be
|
|
cleanly separated.
|
|
|
|
There is no universal consensus whenever use `fun a() = ...` or `fun a() { return ... }`. Yet from reader outlook one-lines seem to better show that the property or function is easily calculated.
|