Формат, комментарии

Пустые строки

Больше одной пустой строки старайся не оставлять на будущее, предлагаю сразу привыкать писать красивый код согласно конвенции стиля Kotlin

Отдели плз переменные от цикла пустой строкой, чтобы было более наглядно. Так код будет выглядеть менее монолитно, что повысит читабельность.

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

`if` , как другие конструкции лучше обосабливать пустыми строками. Это должно уменьшить монолитность кода и сделать его более читабельным.

Предлагаю условные выражения обосабливать пустыми строками, чтобы код не выглядел монолитным

Для красоты лучше разбить код на блоки, разделяемые пустыми строками. Примерно так:
 - объявление переменных
 - вычисления
 - вывод результата

Тут напрашивается обособление пустыми строками принт, а то выглядит слишком монолитно (влияет на читабельность)

Пустые строки затесались, надо обращать на них внимание (больше одной)

Старайся избегать лишних двойных пустых строк) тут и далее по коду
Это размывает внимание, нарушает единый стиль)

Еще предлагаю немного улучшить читабельность (на большом количестве кода это сыграет в плюс). Рекомендую блок с объявлением переменных группировать отделять пустой строкой от всего остального кода, а также внутренние условные выражения сверху и снизу обосабливать пустыми строка. Чтобы визуально они выделялись

Скобки

В Kotlin открываемая скобка ставится на той же строке, что и условие if)

Комментарий к форматированию. согласно конвенции в котлин фигурная скобка функции открывается на той же строке, где функция декларирована — https://kotlinlang.org/docs/coding-conventions.html#formatting

Ок, но в задаче и далее в других [] подразумевает формат, их печатать не нужно

Если это не выражение, то при интерполяции фигурные скобки можно опустить

На этой строке отсутствующий пробел перед двоеточием

Автоформатирование

Не забывай прожимать автоформатирование перед коммитом. по коду в паре мест не хватает пробелов Ctrl+Alt+L (для windows) или ⌥+⌘+L (для osx)

Не забывай прожимать автоформатирование перед коммитом. по коду в паре мест не хватает пробелов

Напоминаю, все арифметические знаки обосабливаются пробелами.

В IDEA есть автоформатирование кода: Находясь в файле Ctrl+Alt+L (для windows) или ⌥+⌘+L (для osx). Рекомендую взять в привычку прожимать автоформат всегда перед коммитом, чтобы все отступы и пробелы расставить по своим местам. 



    Напоминаю про форматирование.
Согласно конвенции стиля Котлин при объявлении типа после двоеточия ставится пробел.
Знаки присваивания также всегда обосабливаются пробелами.

main() и ее аргументы

Здесь и далее в Pull Request’ах аргументы функции `main()` излишни в рамках задач. Мы их никак не используем в задачках, но вернемся в рамках курсовой - будем передавать секретный токен бота, который нежелательно хранить прямо в коде.

На будущее: комментарий про аргументы функции main(). Нам они пока не нужны (понадобятся только на курсовом проекте для токена бота).
Поэтому для чистоты кода предлагаю оставлять их пустыми в следующих тасках.

Предлагаю сразу писать код в исполняемой функции main() Даже, если там нечего запускать в какой-то конкретной задаче.

Согласно конвенции стиля Котлин, перед фигурной скобкой функции ставится пробел.

Длинные строки

Такие многострочные распечатки довольно редко используются и сам код визуально выглядит загруженным. Лучше использовать просто символ переноса строки.

Для длинных условий, которые не помещаются в одну строку, лучше сделать перенос строки после оператора || или &&
Официальная документация [Kotlin Coding Conventions](https://kotlinlang.org/docs/coding-conventions.html) не дает строгих указаний на тему переноса строк внутри условий. Но такой формат я встречал чаще

Очень длинная строка получилась (более 120 символов). В крупных и средних проектах есть системы для автоматизированной проверки кода, например: [Detekt](https://detekt.dev/docs/rules/formatting/#maximumlinelength), который не пропустит такой код. Давай добавим переносов

Комментированный код

Комментарии, не относящиеся к решению или не несущие никакой полезной нагрузки для будущего себя или других разработчиков в команде – лучше не оставлять в продакшн коде.

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

Вопросы лучше писать комментарием к Pull Request'у.

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