Создание временных переменных для улучшения читабельности - PullRequest
7 голосов
/ 05 августа 2010

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

например:

filep->waypt[rp->leg[j]].ID

или

(*(filep->route + filep->nroutes - 1))->number

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

Я только когда-либо проверял свой код в образовательных учреждениях, и я хотел бы знать, что другим легче переварить и где компромиссы производительности (если таковые имеются).

Когда для присвоения значения, чей адрес в памяти, потребовалось бы несколько арифметических операций для вычисления начала собственной переменной, что привело бы к проблемам с производительностью? Будет ли это иметь значение, если сделать это один раз в цикле? Как насчет один раз во вложенном цикле? Как насчет значения, присвоенного его собственной переменной в цикле, но затем доступного во внутреннем цикле?

Как это изменится в интерпретируемом языке? Скажите в PHP (извините за синтаксические ошибки, я новичок в PHP):

$employees[$i][$phone]['Home']['number'];

против

$home = $employees[$i][$phone]['Home']['number'];

И, наконец, если это не слишком субъективно (читабельность кода не должно быть!), Что считается лучшим методом написания читаемого кода? Я пишу код, максимально самодокументируемый, но если переменные начинают становиться слишком надуманными и на них ссылаются несколько раз, я назначу им их собственную переменную. Однако причина, по которой это работает для меня, может заключаться в том, что я привык к своему стилю.

Ответы [ 3 ]

9 голосов
/ 05 августа 2010

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

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

Я считаю, что удобство сопровождения кода гораздо важнее, чем незначительное попадание в хранилище. В качестве (надуманного) примера я бы, вероятно, заменил бы много:

item[last_item-1].id = 14860;
item[last_item-1].name.first = "pax";
item[last_item-1].name.last = "diablo";

звонки с:

tItem lastItem = &(item[last_item-1]);
lastItem->id = 14860;
: : :
// and so on.

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

Но я бы все еще кодировал бы для удобочитаемости. Я не хочу, чтобы в моем коде застряло множество фрагментов $employees[$i][$phone]['Home']['number']. Я бы лучше добавил

$homePhone = $employees[$i][$phone]['Home']['number'];

где-то там и просто используйте $homePhone с этого момента.

1 голос
/ 05 августа 2010

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

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

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

1 голос
/ 05 августа 2010

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

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

Пост Stackoverflow Post по правилам именования в PHP

ОБНОВЛЕНИЕ: удалил мой пример, потому что он был неверным, как указано в комментарии ниже. Я бы по-прежнему рекомендовал использовать переменные для значений, которые повторно используются в функции, так как это улучшает удобочитаемость и удобство обслуживания.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...