Это - хорошая практика для создания некогда используемых переменных?

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

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

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

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

Я полностью с Вашим коллегой в принципе, но не в этом случае.

проблема с одноразовыми переменными состоит в том, что они представляют состояние, и больше состояния означает, что код более трудно понять, так как Вы не знаете, какие эффекты это могло иметь на поток программы. Функциональное программирование не имеет никаких переменных вообще, точно поэтому. Так, чем меньше переменных там, тем лучше. Устранение переменных хорошо.

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

Оба кода являются точно тем же. Конечно, Ваш более читаем, maintenable и debuggable, но, если это было точкой Вашего коллеги, его код НЕ является памятью меньше потребителя.

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

, Если Вы получаете nullpointerexception в этом операторе от Ваших производственных журналов, Вы действительно в беде:

getCustomer () .getOrders () .iterator () .next () .getItems () .iterator () .next () .getProduct () .getName ()

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

Я полностью с Вами на этом.

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

public void OpenDocument(string filename, bool asReadonly, bool copyLocal, bool somethingElse)

мне это намного более читаемо:

bool asReadonly = true;
bool copyLocal = false;
bool somethingElse = true;

OpenDocument("somefile.txt", asReadonly, copyLocal, somethingElse);

.. чем:

OpenDocument("somefile.txt", true, false, true);

Ваш коллега, кажется, не последователен.

единое решение похоже на это:

private void btnGeneral_Click(object sender, RoutedEventArgs e)
{
    UserControl userControl = ((UserControl)type.Assembly).CreateInstance(String.Format("{0}.{1}", this.GetType().Namespace, ((Button)e.OriginalSource).Name));
}

Все Ваши причины кажутся допустимыми мне.

существуют случаи, где Вы эффективно имеете для избегания использования промежуточных переменных, где Вам нужно отдельное выражение (например, для членской инициализации переменной в Java/C#), но представление дополнительной переменной для ясности прекрасно абсолютно, где это применимо. Очевидно, не делайте этого для каждый аргумент каждый метод, но умеренно это может помочь много.

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

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

for (int i1 = 0; i1 < BIG_NR; i1++)
{
  for (int i2 = 0; i2 < BIG_NR; i2++)
  {
    for (int i3 = 0; i3 < BIG_NR; i3++)
    {
      for (int i4 = 0; i4 < BIG_NR; i4++)
      {
        int amount = a + b;
        someVar[i1][i2][i3][i4] = amount;
      }
    }
  }
}

... дополнительное присвоение могло бы оказать слишком большое влияние на производительность. Но в целом, Ваши аргументы на 100% корректны.

Согласованный

"делает код легче читать, т.е. больше Вашего кода "чтения как английский язык",

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

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

Karl

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

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

Кроме того, все это компилируется в MSIL так или иначе, и компилятор оптимизирует много для Вас.

В следующем примере, компилятор оптимизирует код так или иначе:

List<string> someStrings = new List<string>();
for (int i = 0; i < 1000; i++)
{
    string localString = string.Format("prefix{0}", i);
    someStrings.Add(localString);
}

, А не:

List<string> someStrings = new List<string>();
string localString = string.Empty;
for (int i = 0; i < 1000; i++)
{
    localString = string.Format("prefix{0}", i);
    someStrings.Add(localString);
}

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

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

Создание новой переменной означает еще одно понятие для читателя отслеживать. (Рассмотрите крайний случай: интервал b=a; c=b;), Если метод так сложен - в такой потребности разбивания - что дополнительное понятие является ценой, которую стоит заплатить, затем необходимо пойти до конца и разделить его на два метода. Таким образом, Вы получаете и понятное имя и меньший размер. (Меньший для Вашего исходного метода: если это похоже на Вас, говорят, то люди не должны будут обычно читать вспомогательный метод.)

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

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

Thats лучший аргумент против , что я могу придумать! :-)