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

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

20 голосов
/ 20 февраля 2009

Мой коллега изменил этот код: 

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

к этому коду: 

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

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

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

  • функционирует как и уменьшает комментарии (ясно, что такое "userControlFullName")
  • облегчает чтение кода, т. Е. Большая часть вашего кода "читается как английский"
  • избегает сверхдлинных операторов, заменяя их части понятными именами переменных
  • легче отлаживать, так как вы можете навести курсор мыши на имя переменной, и в случаях, например, PHP-программирование без отладчиков, проще выводить эти имена переменных, чтобы получить их значения

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

Кто-нибудь может подумать о каких-либо ситуациях, когда не следует создавать когда-то использованные имена переменных?

Ответы [ 14 ]

1 голос
/ 20 февраля 2009

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

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

0 голосов
/ 20 февраля 2009

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

0 голосов
/ 20 февраля 2009

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

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

Кроме того, все равно все это компилируется в 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);
}

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

0 голосов
/ 20 февраля 2009

Согласовано

"облегчает чтение кода, т. Е. Большая часть вашего кода" читается как английский "

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

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

Karl

Страница:
...