Создание временных переменных для улучшения удобочитаемости
Я хотел бы знать, существуют ли какие-либо значительные недостатки к созданию временной переменной для значения, к которому получают доступ многократно в небольшом объеме.
например:
filep->waypt[rp->leg[j]].ID
или
(*(filep->route + filep->nroutes - 1))->number
Это примеры из недавнего проекта, где я вынудил меня избежать почти любого упрощения для ссылок на переменную для улучшения моих навыков с указателями C (это было болезненно). Однако привычка, казалось, придерживалась. Я нахожу что, чем больше я пытаюсь представить переменные для упрощения моего кода (удобочитаемость и объем ввода), тем более сбивающим с толку это становится для запоминания точно что каждый новые ссылки на переменную.
Мне только когда-либо рассматривали мой код в образовательной установке, и я хотел бы знать то, что другие находят легче к обзору и где компромиссы производительности (если таковые имеются).
То, когда был бы, присваивая значение, кто адрес памяти, потребовало бы, чтобы несколько арифметических операций вычислили свой собственный переменный запуск для порождения проблем производительности? Это имело бы значение, если сделано однажды в цикле? Что относительно однажды во вложенном цикле? Что относительно значения, присвоенного своей собственной переменной в цикле, но, затем получен доступ во внутреннем цикле?
Как это изменилось бы на интерпретируемом языке? Скажите в PHP (извините синтаксические ошибки, я плохо знаком с PHP):
$employees[$i][$phone]['Home']['number'];
по сравнению с
$home = $employees[$i][$phone]['Home']['number'];
И наконец, если это не слишком субъективно (удобочитаемость кода не должна быть!), который считают лучшей практикой для написания читаемого кода? Я пишу код, который максимально самодокументирует, но если переменные начнут слишком изобретаться и будут ссылаться многократно, то я присвою им их собственную переменную. Однако причина, это работает на меня, могла состоять в том, что я привык к своему собственному стилю.
3 ответа
Есть довольно хороший шанс, что любой достойный компилятор обнаружит общие подвыражения и оптимизирует их за вас.
Тем не менее, я бы по-прежнему выбрал временную переменную, если бы она улучшила читаемость моего кода, несмотря на то, что она ввела дополнительное хранилище (хотя и минимальное).
Я считаю, что ремонтопригодность кода гораздо важнее, чем крошечная потеря памяти. В качестве (надуманного) примера я бы, вероятно, заменил множество вызовов:
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.
Что касается интерпретируемых языков, у меня меньше информации по этому поводу. Я довольно много знаю о том, как оптимизировать ассемблерный код (хотя и далеко не так хорошо, как полубоги, которые пишут компиляторы, поэтому я обычно оставляю это им). Я немного меньше знаю о виртуальных машинах, работающих внутри большинства интерпретаторов.
Но я бы по-прежнему оставил код для удобства чтения. Я не хочу, чтобы в моем коде застряла куча фрагментов $ employee [$ i] [$ phone] ['Home'] ['number'] . Я бы предпочел добавить туда
$homePhone = $employees[$i][$phone]['Home']['number'];
и с этого момента просто использовать $ homePhone .
Я бы настоятельно рекомендовал вам использовать переменные для значений, которые вообще используются повторно. Главное - использовать имена переменных, которые действительно описывают, для чего вы используете значение или что это за значение. Также использование переменной для хранения значения и последующего использования переменной значительно упрощает модификацию в будущем и делает ее менее подверженной ошибкам.
Вот некоторые ресурсы по именованию, которые помогут вам правильно именовать переменные. Также не бойтесь комментировать свой код, чтобы знать, для чего предназначена каждая переменная, функция, класс и т.д. Microsofts Naming guidelines
Stackoverflow Post on PHP naming guidelines
UPDATE: удалил свой пример, потому что он был неправильным, как было указано в комментарии ниже. Я все еще рекомендую использовать переменные для значений, которые повторно используются внутри функции, так как это улучшает читаемость и сопровождаемость.
Используйте их для удобства чтения, а также когда вы знаете, что вызов метода, который возвращает значение временной переменной, стоит дорого (например, когда вы запрашиваете кредитный рейтинг у внешнего агентства, вы можете понести как снижение производительности, так и расходы).
В некоторых случаях я не только ввожу временные (также известные как локальные) переменные для лучшей читаемости, но иногда даже извлекаю методы (с помощью инструментов рефакторинга) для одной строки кода, если имя метода помогает понять, что это за код. о.
Я смотрю на производительность тогда и только тогда, когда система уже ведет себя правильно, но еще недостаточно быстра. Таким образом я избегаю оптимизации кода, который еще не находится в окончательной форме или который вообще не нуждается в оптимизации.