Знаешь что? Только не называйте свои переменные temp. Это невероятно плохая практика (нет, у меня нет ОКР). Я видел множество вариантов использования временных переменных в самых разных ситуациях. Но может мне просто не повезло. Позвольте мне показать вам несколько примеров:
Обоснованный случай (псевдо C#)
Это единственная проблема, о которой я могу думать, когда допустимо именование переменной temp. Давайте перейдем к некоторым страшилкам.
Ужас (псевдо C)
Это должно примерно дать вам представление о том, как выглядела эта мерзость функции. Он предназначался для захвата одного флага из последовательного порта. Флаг указывал, какие данные поступают на порт дальше. Поскольку вы знаете, какой тип данных вы собираетесь получить, вы должны прочитать столько байтов, сколько вам нужно для данного типа. Затем код выполнял какие-то магические вычисления, чтобы, наконец, поместить правильно отформатированное значение в какую-либо структуру или глобальную переменную.
Длина функции составляла около 600 строк. Моя самая большая проблема с кодом заключалась в том, что временные переменные использовались во всей функции, и они не просто использовались как контейнеры для хранения значений, они часто изменялись в разных местах и назначались разным переменным.
Очевидно, что приведенный выше дизайн ошибочен. Кто-то может возразить, что повторно использовать переменные таким образом стоит для экономии памяти. Я не согласен по двум причинам:
1. Читабельность кода намного важнее производительности. Если вы беспокоитесь о производительности, сначала напишите код правильно, а затем попытайтесь оптимизировать свой код, если у вас возникнут проблемы с производительностью.
2. Компилятор должен быть достаточно хорош при работе с областями. Если вы объявляете свою переменную в операторе if, а условие для этого оператора не выполняется, то переменная не должна создаваться, что сэкономит вам немного места.
Как мне исправить код?
В зависимости от количества времени, которое у меня было, я бы:
а) провел сложный рефакторинг, создал множество небольших функций для независимой обработки каждого полученного элемента
б) я бы заменил временные переменные множеством осмысленных имен переменных. , то имея более четкое представление о том, к какой переменной осуществляется доступ, я бы попытался максимально ограничить их область действия (в идеале - отдельными случаями в операторе switch).
Вторая страшилка
Этот код… Он настоящий, и он где-то сейчас выполняется. Все временные значения использовались в некоторых матричных расчетах. Просто не делайте этого. Если вы не знаете, что не так с этим кодом, прочитайте Чистый код,
если вы все еще не знаете, почему это плохо, прочитайте Code Complete. . Если вы все еще не понимаете, что не так с этим подходом, то напишите мне, я хочу встретиться с вами.
Мудрые слова
Вот что Стив МакКоннелл говорит о временных переменных в Code Complete (глава 10.8):
Используйте каждую переменную только для одной цели. Иногда возникает соблазн использовать одну переменную в двух разных местах для двух разных действий. Обычно имя переменной не подходит для одного из ее применений или в обоих случаях используется "временная" переменная (с обычным бесполезным именем x или temp).
Заворачивать
Старайтесь давать осмысленные имена переменным. Если вы не можете, то хотя бы замените каждое вхождение «temp» на единорога, по крайней мере, так будет симпатичнее.
Что произойдет, если вы продолжите давать бессмысленные имена своим переменным?
