Мотивация: Если не указывать размерность у константы, можно неправильно её использовать в коде или забыть конвертировать в нужный формат.

// Bad
const val TIMEOUT = 1000L
const val PADDING = 24

// Good
const val TIMEOUT_MILLIS = 1000L
const val PADDING_DP = 24

// Good
val TIMEOUT = 1000.milliseconds
val PADDING = 24.dp

В тексте заметил несколько ошибок, предлагаю поправить.

https://github.com/RedMadRobot/kotlin-style-guide#lambda_formating

[При использовании лямба-функции в качестве аругмента выносить её за скобки если этот параметр единственный.]

Избегать использования Destrucion Declaration в лямбда-выражениях.

https://github.com/RedMadRobot/kotlin-style-guide#classes

Если описание класса не помещается в одну строку и реализует несколько интерфейсов (класс реализует или описание?), то применять стандартные правила переносов, т.е. делать перенос только в случае, когда не помещается на одну строку (не помещается что?), и продолжать перечисление интерфейсов на следующей строке.

Предлагаю исправить на: "Если описание класса не помещается в одну строку, и класс реализует несколько интерфейсов, то применять стандартные правила переносов, т.е. делать перенос только в случае, когда описание не помещается на одну строку, при этом продолжать перечисление интерфейсов на следующей строке.

https://github.com/RedMadRobot/kotlin-style-guide#condition_operator

У оператора when для коротких выражениях ветвей условия
when (somenCondition) {

Две пустых строки вместо одной:

when (feed.type) {
        FeedType.PERSONAL -> {
        	with(feed as PersonalFeed) {
        		datePopupStart = dateBegin
        		datePopupEnd = dateEnd
        	}
        }
// 1
// 2
        FeedType.SUM -> {

Добавить правила использования when. Например если он используется в таком контексте

sealed class AState {
    class Started() : AState()
    class Finished() : AState()
}

Если в конкретном бизнес процессе нас интересует только состояние Started то можно опустить вторую проверку

when (value) {
    is AState.Started -> {
    //.. 
    }
   //проверка Finished опущена за ненадобностью обработки
}

Зачем это? Мне кажется так проще дополнять возможные обработки в будущем (например если нам в этом бизнес процессе потребуется обрабатывать и Finished). Также такая конструкция оставляет вопрос конечного автомата открытым и расширяемым

PS
Думаю справедливо применить это правило только для использование с sealed классами. Простые же выражения выносить в if блоки

var a = 5
//... bad
when (a) {
    5 -> {
    //.....
    }
}
// okay

if (a==5) //..

Предлагаю заменить формулировку:

Элвис оператор ?: при разрыве выражения также переносится на новую строку

на

Элвис оператор ?: в многострочном выражении также переносится на новую строку

Это подчеркнёт то, что элвис лучше отделять переносом всегда кроме случая однострочника.

Придумать способ синхронизации нашего внутреннего документа с этим репозиторием.

В блоке про Именованные аргументы на мой взгляд слишком много завязано на количество элементов, а не на логику.

Я бы заменил

Если аргументов больше 3х,то следует их именовать.

на

Если значение аргумента не говорит о том, что это за параметр, то следует именовать аргумент.

Потому что даже пример

runOperation(
    method = operation::run,
    consumer = consumer,
    errorHandler = errorHandler,
    tag = tag,
    cache = cache,
    cacheMode = cacheMode
)

читается хуже, чем когда по смыслу

runOperation(
    method = operation::run,
    consumer,
    errorHandler,
    tag,
    cache,
    cacheMode
)

Что-то похожее есть сейчас в той части, где про примитивы:

Именовать аргументы примитивных типов. При этом если аргумент один, и из контекста вызова функции понятно для чего он нужен, то можно его не именовать.

Правило про именование примитивов я бы убрал тоже. Не стоит основываться на том примитив ли это. Лучше всё так же на том, понятно ли по значению или имени функции, что это за параметр.

При использовании compose, часто возникают ситуации когда мы хотим прятать вьюху по какому то флагу.

Что-то в духе:
if (isVisible) Button()

Сейчас в style guide есть такой пункт:

Не обрамлять if выражения в фигурные скобки только если условный оператор if помещается в одну строку.

Но так как у всех вьюх куча параметров, по style guide пример выше надо написать вот так:

if (isVisible) {
   Button(
    .....
   )
}

Есть идея разрешить в случае с компоузом делать вот так:

if (title != null) Text(
    text = title,
    modifier = Modifier.padding(horizontal = 32.dp),
    style = SbiTextStyles.Title,
    textAlign = TextAlign.Center,
)

Но если есть else - мне кажется, скобки обязательны.

Это правило очень сильно идет в разрез с тем что написано в Kotlin Coding Conventions

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 (org.example.myProject).

и в Android Kotlin Style Guide

Package names are all lowercase, with consecutive words simply concatenated together (no underscores).

Предлагаю убрать это правило и всю секцию, пользоваться тем что есть в официальных гайдах.

В #13 предложена такая последовательность в структуре класса:

...
3. Абстрактные методы
4. Переопределенные методы родительского класса (желательно в порядке их следования в родительском классе)
5. Реализации методов интерфейсов (желательно в порядке добавления интерфейсов в класс и следования методов в каждом интерфейсе)
6. Методы класса (в логическом порядке. Например, метод располагается после того, в котором впервые упомянут). 
...

Было бы хорошо также разрешить перемешивать abstract и override методы с методами класса, чтобы была единая логика относительно всех методов (например, метод располагается после того, в котором впервые упомянут).

Считаю, что вот так:

override fun onSomeActionInSuperclass() {
  doSomethingHere()
}

private fun doSomethingHere() {
  ...
}

override fun onAnotherActionInSuperclass() {
  ...
}

будет читаться лучше чем

override fun onSomeActionInSuperclass() {
  doSomethingHere()
}

override fun onAnotherActionInSuperclass() {
  ...
}

private fun doSomethingHere() {
  ...
}

Что думаете?

Сочетание "Гусь и Элвис" (?. ?:) в многострочных выражениях пишем на новых строках:

// OK
child?.let { println(it) } ?: println(parent)

// Хорошо
child
    ?.let {
        println(it)
    }
    ?: println(parent)

// Плохо
child?.let {
    println(it)
} ?: println(parent)

В более сложных случаях следует заменять на if/else:

// Лучше
if (child != null) {
    println(child)
	// ...
} else {
    println(parent)
    //...
}

Предпосылки - сложность чтения ситуации как эта:

// Плохо
child?.let {
    println(it)
} ?: println(parent)

А в реальных случаях кода больше и легко пропустить условие идущее после элвиса.

Сейчас в разделе Структура класса есть порядок методов по области видимости:

6. public методы
7. internal методы
8. protected методы
9. private методы

Это ухудшает читаемость кода и накладывает дополнительные затраты на форматирование кода.
Располагать публичные методы вверху полезно только для библиотек, а во внутренних классах это не несет особой пользы. А увидеть в порядке видимости можно в студии открыв окошко Structure и выбрав Sort by Visibility.

Обычно чтение класса происходит сверху вниз, поэтому удобнее располагать методы по мере использования. Если в одном методе встретился вызов другого, то он идет сразу за ним. Так не нужно листать в конец класса, чтобы увидеть этот метод. Насколько я помню, именно такой вариант советует Дядюшка Боб в книге Чистый код.

А вот что написано про это в официальных гайдах:
Андроид:

What is important is that each file uses some logical order, which its maintainer could explain if asked. For example, new functions are not just habitually added to the end of the file, as that would yield “chronological by date added” ordering, which is not a logical ordering.

Котлин:

Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom can follow the logic of what's happening. Choose an order (either higher-level stuff first, or vice versa) and stick to it.

С приходом Compose лямбды теперь передаём в параметрах чаще и необходимость явно прописывать invoke, как мне кажется, только усложняет чтение кода.
Пример:

@Composable
fun ProfileScreenContent(
    header: @Composable LazyItemScope.() -> Unit,
    body: LazyListScope.() -> Unit,
    footer: @Composable LazyItemScope.() -> Unit,
) {
    LazyColumn {
        item(content = header)
        // Что тут происходит? Передаём параметр в лямбду?
        // А, нет. Передаём контекст, на котором нужно вызвать лямбду
        body.invoke(this@LazyColumn)
        // При этом не вижу проблем с вызовом без invoke, исчезает куча лишней информации
        body()
        item(content = footer)
    }
}

Я в очередной раз забыл какие были аргументы за то чтобы явно вызывать invoke, хорошо если кто-нибудь напишет их в комментариях.

В раздел Аннотации добавить пункт о том, что аннотация, применяемая к primary конструктору, располагается на той же строке.

Пример:

class Example @Inject constructor() {
}

Чтобы можно было так:

    private fun moo(mo: String) = when (mo) {
        "you",
        "and",
        "me" -> true
        else -> false
    }

    private fun foo() =
        try {
            if ("ohhh" == "you touch my talalam") {
                throw IllegalStateException("It's din din dong")
            }
            "magic"
        } catch (e: Exception) {
            println("ta talala talalalala")

            "the gathering"
        }

Сейчас можно только так:

    private fun moo(mo: String): Any {
        return when (mo) {
            "you",
            "and",
            "me" -> true
            else -> false
        }
    }

    private fun foo(): String {
        return try {
            if ("ohhh" == "you touch my talalam") {
                throw IllegalStateException("It's din din dong")
            }
            "magic"
        } catch (e: Exception) {
            println("ta talala talalalala")

            "the gathering"
        }
    }