Нейминг, типы, Null Safety¶
Типы¶
В практике, в большинстве коммерческих проектов так конкретно типы указываются довольно редко. Если это не условно высокоточная программа уровня космонавтики, то в остальных случаях это экономия на спичках. Это для информации, ни в коем случае не ошибка.
Переменные¶
Однобуквенные переменные - зло, они уместны только в циклах в качестве интерируемой переменной, в остальном - теряется контекст в месте использования переменной. Давай дадим понятное название
Для всех объявленных переменных нужны какие-то релевантные названия. иначе сложно ориентироваться в коде, особенно, если видишь его впервые. или спустя какое-то время
Лучше использовать более понятный нейминг. Иначе сложно быстро войти в контекст для чего нужны эти переменные в рамках большой программы
В переменной на текущей строке содержится два слова. Предлагаю использовать стиль [lowerCamelCase](https://ru.wikipedia.org/wiki/CamelCase)
Boolean¶
Boolean переменные принято называть isWeatherSolar (не обязательно, но так код легче читается). Давай назовем isTentOpen, это касается и констант - IS_WEATHER_SOLAR, т.е. отвечающие на вопрос да/нет.
Рекомендуется Boolean переменные называть, "отвечая на вопрос“ да/нет. Ну и принято название начинать для них с `is`, в редких случаях `has`. Например, hasDamage, isDamaged.
Классы¶
Null Safety¶
Оператор !! (Not-null assertion)¶
Использование оператора `!!` подразумевает, что ты уверен в том, что значение не может быть `null`. Однако, если это не так, то приложение "упадет" с ошибкой. Поэтому этот оператор считается опасным и не рекомендуется использовать. Только в крайних случаях.
Это противоречит основной идее безопасности типов в Kotlin, поэтому лучше использовать альтернативные способы обработки нулабельных значений. Такие как оператор безопасного вызова `?.`, элвис-оператор `?:` или оператор `let`.
readLine()!!
Использование оператора `!!` подразумевает, что ты уверен в том, что значение не может быть `null`. Однако, если это не так, то приложение "упадет" с ошибкой. Поэтому этот оператор считается опасным и не рекомендуется использовать. Только в крайних случаях.
Это противоречит основной идее безопасности типов в Kotlin, поэтому лучше использовать альтернативные способы обработки нулабельных значений. Такие как оператор безопасного вызова `?.`, элвис-оператор `?:` или оператор `let`.
Но пока я рекомендую использовать более свежую функцию `readln()`. Метод под капотом обрабатывает нулябельность и все кастует в строку (в том числе `null` становится строкой `“null”`.
В данном случае лучше использовать функцию `readln()`, которая не будет выбрасывать исключение, если в нее прийдет `null`, а просто вернет строку (строка будет конфликтовать с приведением к целочисленному типу, но это другой кейс, важнее разобраться с нулябельностью)
Оператор `!!` (утверждение “это не `null`”) использовать не рекомендуется. При получении null, программа упадет с ошибкой. Подробнее об этом будет в дальнейших уроках [https://youtu.be/hf4vrHucYNU](https://youtu.be/hf4vrHucYNU)
Здесь же рекомендую использовать `readln()` - метод уже обрабатывает нуллябельность, дополнительная обработка не нужна и любые значения приводятся к строке.
Приведение nullable (и не только) к строке через .toString()¶
`.toString()` здесь выступает в качестве очень неудачного костыля. Убери приведение и посмотри внимательнее на ошибке. Метод authorizesVerifies должен вернуть нулябельную строку, но метод generateToken не возвращает ничего. По умолчанию это тип Unit, который ты и пытаешься вернуть из текущего метода в виде строкового типа.
Можно поставить здесь точку останова и запустить дебаг, увидишь что происходит в этой строке на момент выполнения. Старайся вообще чаще пользоваться дебаггером и не добавлять необдуманный код, только чтобы программа собралась)