Ну и к тому же, если метод достаточно большой, то лучше подумать над именем переменной

Вообще лучше всегда думать, как и что ты называешь

Переделал. Строки с потолка было взял, а вот с числами такое бывает

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

Мне кажется на такую бурду лучше уже класс как-то делать

И все же где такое нужно может быть - хз

Не согласен, вообще никак

Видел код, где бракованные изделия подписывались как marriage

Смотри, если ты написал шикарную логику, но при этом на стиль кода, наименование переменных и т.д. не тратил время, то при возврате в этот код через некоторое время ты хрен что поймёшь. А не дай бог кто то другой в этом говне разбираться будет
Код чаще читается, чем пишется. Это помнить нужно и не забывать

В котлине все структуры данных объявляются через шаблоны. С одной стороны, однородность. Set<Any> HashMap<Any> и Array<Any> выглядят совершенно одинаково, и не нужно применять к массивам один подход, а к остальным структурам - другой. Но с другой стороны, это и повод для критики. Однажды наткнулся на один коммент, мол, делал я на вашем котлине сложную векторную математику. Задолбался путать Array<Array<Array<Int>>> и Array<Array<Array<Array<Int>>>>.

Вот помню как-то хотел макрос написать на проверку пересечений. Открыл справку, а там такое. Я плюнул разбираться с этими измерениями.

Зачем был нужен последний уровень вложенности?

Да легко же. Достаточно посчитать кол-во треугольников в конце)

Я хз зачем он автору коммента понадобился, не умею в векторную математику. Но иногда написать int[][][] реально проще чем Array<Array<Array<Int>>>

Дело вкуса и привычки

Безумец, но да

В 99% времени похрен

Проще

Я не забиваю болт на название Ия, просто пишу типы вместо вар и не сижу по хуелиону часов за придумыванием названий, когда возвращаюсь назад, то типы и названия замечательно дополняют читаемость кода, а если бы я имел в коде что-то типа var company = GetActiveCompany(), то я бы не особо понял, о каком объекте идёт речь