forked from kscience/kmath
36 lines
1.6 KiB
Markdown
36 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.
|