Длинные имена переменных – зло.  Naming is hard. Это правда, и вот почему. Во-первых, у нас пока нет метрики, которая может сказать, что вот этот нэйминг плохой, а вот это хороший. Думаю через год или два ИИ линтер сможет предлагать варианты наименований. А пока выкручиваемся как можем. Во-вторых, бытует мнение, якобы длинные и исчерпывающие имена – это хорошо. Чистый код на максималках такой. Например, readFileFromPathAndThrowExceptinIfNoSuchFile(Path absolutePathToFile). Ну круто же! Одна сигнатура уже говорит о том, что делается и тело метода даже читать не надо! Комментарии не нужны!  В какой-то степени это имеет смысл. За неимением лучшего можно писать так. Но что, если есть более простой и лаконичный способ? Я говорю про правильное разграничение ответственностей. Абстракции короче. В выдуманном примере смешиваются несколько уровней абстракции: формат ошибки (exception), представление пути в файловой системе (Path), формат пути (absolute). Все это повышает когнитивную нагрузку на читателя. Представьте себе сто строк кода, написанных вот в таком стиле дедушки Боба! Брр... Люди не могут держать большое количество деталей в голове одновременно. Я не могу думать о бизнес логике и в этот же момент видеть какие-то обработки ошибок, которые конкретно на бизнес логику не влияют. Я начинаю отсекать эти детали, чтобы просто не сойти с ума.  Мысль предельно проста. Давайте разделим код на уровни абстракции и будем использовать имена, которые соответствуют текущему уровню абстракции. Наверху у нас readFile, дальше идут проверки на корректность пути и бросание эксепшенов. Еще ниже сами придумайте.  За удивительной простотой мысли скрывается колоссальная сложность. Куда проще запихать поток мыслей в имя переменной, чем рассортировать этот поток на уровни и понять что действительно важно, а что можно скрыть за следующим уровнем абстракции. Это и есть искусство проектирования и написания кода.