Почему ReSharper инвертирует IFs для кода С#? Отличается ли производительность (даже немного)?

Рассмотрим следующий пример кода:

private void AddEnvelope(MailMessage mail)
{
    if (this.CopyEnvelope)
    {
        // Perform a few operations
    }
}

против

private void AddEnvelope(MailMessage mail)
{
    if (!this.CopyEnvelope) return;
    // Perform a few operations
}

Будет ли нижний код работать быстрее? Почему ReSharper вынести эту рекомендацию?

Обновить

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

Ответы

Ответ 1

Обновленный ответ:

Это предложение поддержки. Легче читать, чем вложить остальную часть кода в оператор IF. Примеры/обсуждение этого можно увидеть по следующим ссылкам:

Исходный ответ:

Он будет работать (очень пренебрежимо) от того, чтобы выполнить НЕ работает.

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Единственный раз, когда я могу думать о том, что имеет смысл оптимизировать ваши операторы if, это когда у вас есть результаты двух или более длинных запущенных методов, которые необходимо объединить, чтобы определить, чтобы сделать что-то еще. Вы бы хотели выполнить только вторую операцию, если первая операция дала результаты, которые передавали бы условие. Полагая тот, который, скорее всего, вернет false, обычно будет разумным выбором. Это потому, что если оно ложно, второе не будет оцениваться вообще. Опять же, стоит только беспокоиться о том, являются ли операции значительными, и вы можете предсказать, с какой вероятностью пройти или провалиться. Инвертируйте это для OR... если true, он будет оценивать только первый и так оптимизировать. т.е.

if (ThisOneUsuallyPasses() && ThisOneUsuallyFails())

не так хорош, как

if (ThisOneUsuallyFails() && ThisOneUsuallyPasses())

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

Лучше беспокоиться о том, как вы используете строки, коллекции, индексируете свою базу данных и выделяете объекты, а не тратите много времени на то, чтобы беспокоиться об одном условии if, если вы беспокоитесь о перфомансе.

В общем, то, что дает нижний код, вы даете вам возможность избежать огромного блока кода внутри оператора if, который может привести к глупым ошибкам, зависящим от типа. Старое школьное мышление состояло в том, что вы должны иметь только одно очко, которое вы возвращаете из метода, чтобы избежать другой породы ошибки кодера. Нынешнее мышление (по крайней мере, некоторыми поставщиками инструментов, такими как resraarper jetbrains и т.д.), Похоже, что лучше всего сократить наименьшее количество кода внутри условных операторов. Что-нибудь большее, чем это было бы субъективно, поэтому я оставлю это на этом.

Ответ 5

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

Ответ 6

Требуемое чтение: Cyclomatic_complexity

Cyclomatic Complexity - количественная мера числа линейно независимых пути через исходный код программы

Это означает, что каждый раз, когда вы вступаете в ветки с помощью выражения if, вы увеличиваете Cyclomatic Complexity на 1.

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

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

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

Удалив операторы if, ваша сложность кода уменьшается, как и количество тестовых случаев, необходимых для тестирования.