Стоит ли создавать дополнительные переменные для лучшей читаемости кода?

Question

[Анастасия Соболева]

Можно писать хорошо читаемый и самодокументируемый код, но иногда для этого нужно создавать дополнительные переменные и разбивать строки кода. Насколько хороша или плоха подобная практика?

Простой пример:

// $prices - двумерный массив с ценами
// $type - тип параметра
foreach($prices as $price) {
    $amount = $price[$type];
    $total += $amount;
}

Более короткий вариант:

// $prices - двумерный массив с ценами
// $type - тип параметра
foreach($prices as $price) {
    $total += $price[$type];
}

Какой стиль предпочтительнее?

Comments

[Анастасия Соболева]

Пример на PHP, но интересует вопрос в общем

[copal]

В большинстве случаев у Вас это должно происходить само сабой, то есть - User.fullName = user.lastName + user.secondName; Другими словами в 98% кода Вы должны "жонглировать" объектами.

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

Но в конкретном примере я за второй вариант, если как сказали ниже Вы не обращаетесь к переменной массива несколько раз.

[Анастасия Соболева]

copal: Спасибо, солидарна

Answer 1

[Алексей Николаев]

Зависит от ситуации. В вашем примере - второй. Но, в случае с кодом ниже - первый.

foreach($houses as $house) {
    $current_floor = $house[$floor];
    $rooms_count = count($current_floor['flats']['1-room']); // например, только 1-комнатные

    $total_rooms += $rooms_count;

    /* вышенаписанное гораздо лучше, чем
    $total_rooms += count($house[$current_floor]['flats']['1-room']);
    */
}

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

Comments

[Назар Мокринский]

$floor = $house[$floor]; в цикле весьма подозрительно смотрится)

[Алексей Николаев]

Назар Мокринский: опечатка, исправил)

[xmoonlight]

Алексей Николаев : "вышенаписанное гораздо лучше, чем..." - я бы так не сказал)

Answer 2

[Mikhail Osher]

Я смотрю на следующие критерии, чтобы вынести в переменную:
1) collection[key] используется более одного раза
2) key слишком тяжелый (complicated) - тогда выношу ключ (сохраняя логику пункта 1)

Comments

[Толстый Лорри]

Это уже оптимизации, а не улучшение читабельности.

[Анастасия Соболева]

Спасибо, интересно. Тоже об этом думала, т.к. создавать одну переменную ради одноразового использования как-то странно. Но с другой стороны именно так рекомендует Макконнелл в книге "Совершенный код" в первую очередь для более легкого чтения и самодокументирования.

[Анастасия Соболева]

Толстый Лорри: Да, получается мелкая оптимизация за счет небольшого ухудшения читаемости. Что думаете по поводу изначального вопроса?

[Толстый Лорри]

Анастасия Соболева: Насколько она мелкая - от ситуации зависит. Скажем, кэш результатов запроса к стороннему сервису может быть полезен. Просто у этого действия совсем другая мотивация.

Answer 3

[Толстый Лорри]

Здесь не бывает универсальных правил. Посмотрите на код свежим взглядом и подумайте, будут ли очевидны шаги алгоритма при белглом промотре?
Еще можно опираться на близость алгоритма к естественному языку: "для каждого ценника к общему прибавить ценник определенного типа". То есть дополнительная переменная здесь скорее добавляет многословности - лишнюю сущность, который нужно держать в голове.

Answer 4

[xmoonlight]

2-й.
он не только более короткий, но и намного менее ресурсозатратный.
Ну, и... "ломик в рукаве": php.net/manual/ru/function.array-sum.php

Comments

[Анастасия Соболева]

Намного? Неужели создание одной переменной в существующем мире намного затратнее? :) С точки зрения ресурсов - это экономия на спичках. Кроме этого, можно привести более сложный пример кода, где в первом случае будет значительно все более понятно, чем во втором (много данных и операций в одной длинной строке вместо нескольких коротких строках).

[xmoonlight]

Анастасия Соболева: 1. создание одной лишней да и в нескольких местах одного проекта...
2. от кол-ва строк - это не зависит. зависит от выделяемой памяти и кол-ва арифм. и логич. операций.

[Анастасия Соболева]

P.S. array_sum() в данном случае не используется, т.к. пример выдуман специально для вопроса.

[Максим Тимофеев]

Анастасия Соболева: С точки зрения 1 примера - да, а с точки зрения проекта - нет. Да и почему не сэкономить ресурс там где это возможно и просто. Это никак не влияет на читаемость кода.

Answer 5

[Максим Тимофеев]

А проще так:

$total = array_column($prices, $type);
$total = array_sum($total);

Comments

[Анастасия Соболева]

Почему бы тогда не соединить эти две строки в одну? :) В первой строке $total явно не выполняет своей конечной сущности, т.к. является промежуточной переменной.

[Максим Тимофеев]

Анастасия Соболева: Нагляднее, но лишней переменной нет

[abcd0x00]

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

[Максим Тимофеев]

abcd0x00: обоснуйте

[abcd0x00]

Максим Тимофеев: Таким макаром ты никогда не знаешь, что находится в total. К примеру, где-то в коде написано print(total). Чтобы понять, что выводится, ты не можешь просто взять и найти то место, где total создана, потому что где-то в середине она может быть изменена вот таким вот неграмотным путём. В результате, тебе сначала нужно перечитать весь код, от создания total до print(total), чтобы проследить всю её историю. И только после этого ты можешь быть уверен, что выводится то-то и то-то. Но даже это тебя не спасёт, потому что потом где-то в середине строка перекрытия может быть добавлена или удалена.

[Максим Тимофеев]

abcd0x00: Ну 20 строк с одной переменной может быть проблематично, но конкретно эти две строки не станут проблемой.

[abcd0x00]

Максим Тимофеев: Тут можно вообще вызов в вызов вставить. Просто предрасположенность к перекрытию заставит перечивать код. Если у тебя проект на 1000 строк, то можно его весь даже наизусть выучить. Но когда у тебя проект на 100000 строк, да и писал его не ты, то у тебя просто нет времени на чтение.