Всегда ли целесообразно объявлять переменную?

Я новичок в С# и любой форме программирования, и у меня есть вопрос, который, по-видимому, делит тех, кто знает в моем университетском факультете. Этот вопрос просто: всегда ли я должен объявлять переменную? В качестве базового примера того, о чем я говорю: если мне есть int pounds и int pence, мне нужно объявить int money, в который нужно поставить ответ, или это нормально:

textbox1.Text = (pounds + pence).ToString();

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

Спасибо заранее.

Ответы

Ответ 1

По-моему, ответ "нет". Однако в некоторых случаях вы должны использовать переменные:

Всякий раз, когда значение используется несколько раз
Когда выполняется вызов дорогостоящей функции или у кого есть побочные эффекты
Когда выражение должно быть сделано более самоочевидным, переменная (со значимыми именами) поможет

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

Ответ 2

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

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

Ответ 3

Абсолютно нет. Единственный раз, когда я создавал переменную для одного использования, например, это, если это значительно увеличивает читабельность моего кода.

Ответ 4

По-моему, если вы делаете что-то вроде

int a = SomeFunc();
int b = SomeFunc2();
int c = a + b;
SomeFunc3(c);

лучше просто сделать

int a = SomeFunc();
int b = SomeFunc2();
SomeFunc3(a + b);

или даже просто

SomeFunc3(SomeFunc() + SomeFunc2());

Если я не манипулирую с переменной после ее вычисления, я думаю, что лучше не объявлять ее, потому что вы просто получаете больше строк кода и больше места, чтобы позже совершить ошибку, когда ваш код станет больше

Ответ 5

Переменные служат для выполнения следующих двух целей, прежде всего:

Держатель места для данных (и информации)
Усилитель удобочитаемости

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

Вышеуказанные два момента имеют одинаковую важность, насколько мне известно.

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

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

Ответ 6

Я бы предположил, что регистрация часто делает объявление переменной допустимым, и когда вам нужно знать, что-то конкретное, и вам нужно отслеживать это конкретное значение. И вы регистрируетесь, не так ли? Регистрация хороша. Регистрация правильная. Регистрация - это свобода, единороги и счастливые вещи.

Я не всегда использую переменную. В качестве примера, если есть метод, оценивающий что-то и возвращающий true/false, я обычно возвращаю выражение. Результаты регистрируются в другом месте, и у меня есть входные записи, поэтому я всегда знаю, что произошло.

Ответ 7

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

Ответ 8

В принятии этого решения есть две цели:

Считываемость - код доступен для чтения и понятный код
Оптимизация - код не имеет любой ненужный расчет

Если вы рассматриваете это как проблему оптимизации, это может показаться менее субъективным

Наиболее читаемым по шкале от 1 до 10 с 10, что является самым простым. Использование разумных имен переменных может дать вам 2, показывая, что расчет в строке может дать вам 3 (так как пользователю не нужно искать, что такое "деньги", это просто в этой строке кода). и т.д. Эта часть субъективна, вы и компании, с которыми работаете, определяете то, что читаемо, и вы можете построить эту модель затрат из этого опыта.

Наиболее оптимальное исполнение не является субъективным. Если вы пишете "фунты + пенс" везде, где вы хотите, чтобы расчет денег шел, вы теряете время процессора. Да, я знаю, что дополнение - плохой пример, но он по-прежнему сохраняется. Скажем, минимальное выполнение процесса упрощается для распределения памяти переменных, назначений и вычислений. Возможно, одно или два из этих дополнений в коде будут в порядке для удобочитаемости, но в какой-то момент это станет полной потерей на процессоре. Вот почему существуют переменные, выделяют некоторое пространство для хранения значения, назовите его деньги, чтобы пользователь знал, что это такое, и ссылайтесь на эту переменную "деньги" везде, где она была нужна.

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

money = factor[1] + factor[2] + ... + factor[n]

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

Короче говоря, если вы используете деньги только один раз и ясно, что означает встроенный расчет, то, конечно, не делайте переменную. Если вы планируете использовать его во всем своем коде, и это означает, что он становится путаным, тогда объявите переменную, сохраните процессор и сделайте это! Примечание: частично издеваясь над этим подходом, просто подумал, что смешно отвечать на что-то подобное в формате модели затрат:) по-прежнему полезен. Я говорю

Ответ 9

Локализация и область действия

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

void f()
{
    int x = ...;  // "we need x (or side effect) in next scope AND
                  // thereafter..."

    {
         int n = ...;  // "n isn't needed at function scope..."
         ...
    } // can "pop" that n mentally...

    ...
}

Самый маленький объем - это буквальный или временный результат. Если значение используется только тогда, когда я предпочитаю использовать комментарии, а не переменную (они не ограничены A-Za-z0-9_ либо: -)):

x = employees.find("*",                       // name
                   retirement.qualify_at(),   // age
                   num_wives() + num_kids()); // # dependents

краткость

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

сохранить полезную документацию целевую и лаконичную

Ответ 10

Я не помню, чтобы когда-либо видел что-то подобное, и я думаю, что он больше привязан к разным "стилям" программирования. Некоторые стили, такие как Spartan, на самом деле пытаются объявить как можно меньше. Если вы не пытаетесь следовать определенному стилю, тогда лучше всего отказаться от читаемости. В вашем примере я бы не объявлял специальную переменную для ее хранения. Это вы рассчитывали налоги, основанные на некотором проценте от общего числа тех, и я могу - или, по крайней мере, я бы прокомментировал то, что я рассчитывал.