Блог

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

например, это:

 if (SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall())
{
    // do stuff
}
 

в это

 bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();

if (b1 || b2)
{
    //do stuff
}
 

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

Но с этим извлечением я потерял оценку короткого замыкания (SCE).

1. Я действительно теряю SCE каждый раз? Существует ли какой-либо сценарий, в котором компилятору разрешено «оптимизировать его» и при этом предоставлять SCE?
2. Существуют ли способы сохранить улучшенную удобочитаемость второго фрагмента без потери SCE?

Одно естественное решение будет выглядеть так:

 bool b1 = SomeCondition();
bool b2 = b1 || SomeOtherCondition();
bool b3 = b2 || SomeThirdCondition();
// any other condition
bool bn = bn_1 || SomeFinalCondition();

if (bn)
{
  // do stuff
}
 

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

Это было мое первоначальное решение: хорошим шаблоном в вызовах методов и телах цикла for является следующее:

 if (!SomeComplicatedFunctionCall())
   return; // or continue

if (!SomeOtherComplicatedFunctionCall())
   return; // or continue

// do stuff
 

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

Я склонен разбивать условия на несколько строк, т.е.:

 if( SomeComplicatedFunctionCall()
 || OtherComplicatedFunctionCall()
  ) {
 

Даже при работе с несколькими операторами (amp;amp; ) вам просто нужно увеличить отступ с каждой парой скобок. SCE все еще работает — нет необходимости использовать переменные. Написание кода таким образом сделало его гораздо более понятным для меня уже много лет. Более сложный пример:

 if( one()
 ||( two()> 1337
  amp;amp;( three()== 'foo'
   || four()
    )
   )
 || five()!= 3.1415
  ) {
 

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

 bool b = SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
if (b amp;amp; some_other_expression) { ... }
 

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

 auto e = []()
{
    return SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
};

if (e() amp;amp; some_other_expression) { ... }
 

1) Да, у вас больше нет SCE. В противном случае у вас было бы это

 bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();
 

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

2) Это основано на мнениях, но для достаточно сложных выражений вы можете сделать:

 if (SomeComplicatedFunctionCall()
    || OtherComplicatedFunctionCall()) {
 

Если это слишком сложно, очевидным решением является создание функции, которая вычисляет выражение и вызывает его.

Вы также можете использовать:

 bool b = someComplicatedStuff();
b = b || otherComplicatedStuff(); // it has to be: b = b || ...;  b |= ...; is bitwise OR and SCE is not working then 
 

и SCE будет работать.

Но это не намного более читабельно, чем, например:

 if (
    someComplicatedStuff()
    ||
    otherComplicatedStuff()
   )
 

1) Действительно ли я каждый раз теряю SCE? Является ли компилятор каким-либо сценарием, позволяющим «оптимизировать его» и по-прежнему обеспечивать SCE?

Я не думаю, что такая оптимизация разрешена; особенно OtherComplicatedFunctionCall() могут быть некоторые побочные эффекты.

2) Какова наилучшая практика в такой ситуации? Это единственная возможность (когда я хочу SCE) иметь все, что мне нужно, непосредственно внутри if и «просто отформатировать его так, чтобы оно было максимально читаемым»?

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

 bool getSomeResult() {
    return SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
}

...

if (getSomeResult())
{
    //do stuff
}
 

И поскольку мы реализуем getSomeResult() на основе SomeComplicatedFunctionCall() и OtherComplicatedFunctionCall() , мы могли бы рекурсивно разложить их, если они все еще сложны.

1) Действительно ли я каждый раз теряю SCE? Является ли компилятор каким-либо сценарием, позволяющим «оптимизировать его» и по-прежнему обеспечивать SCE?

Нет, вы этого не делаете, но он применяется по-другому:

 if (SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall())
{
    // do stuff
}
 

Здесь компилятор даже не будет запускаться OtherComplicatedFunctionCall() , если SomeComplicatedFunctionCall() возвращает true .

 bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();

if (b1 || b2)
{
    //do stuff
}
 

Здесь обе функции будут выполняться, потому что они должны быть сохранены в b1 и b2 . Ff b1 == true тогда b2 не будет оцениваться (SCE). Но OtherComplicatedFunctionCall() уже был запущен.

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

2) Какова наилучшая практика в такой ситуации? Это единственная возможность (когда я хочу SCE) иметь все, что мне нужно, непосредственно внутри if и «просто отформатировать его так, чтобы оно было максимально читаемым»?

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

Еще одна возможность короткого замыкания и наличия условий в одном месте:

 bool (* conditions [])()= {amp;a, amp;b, ...}; // list of conditions
bool conditionsHold = true;
for(int i= 0; i < sizeOf(conditions); i   ){
     if (!conditions[i]()){;
         conditionsHold = false;
         break;
     }
}
//conditionsHold is true if all conditions were met, otherwise false
 

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

Очень странно: вы говорите о удобочитаемости, когда никто не упоминает использование комментариев в коде:

 if (somecomplicated_function() || // let me explain what this function does
    someother_function())         // this function does something else
...
 

Кроме того, я всегда предваряю свои функции некоторыми комментариями о самой функции, о ее вводе и выводе, и иногда я привожу пример, как вы можете видеть здесь:

 /*---------------------------*/
/*! interpolates between values
* @param[in] X_axis : contains X-values
* @param[in] Y_axis : contains Y-values
* @param[in] value  : X-value, input to the interpolation process
* @return[out]      : the interpolated value
* @example          : interpolate([2,0],[3,2],2.4) -> 0.8
*/
int interpolate(std::vector<int>amp; X_axis, std::vector<int>amp; Y_axis, int value)
 

Очевидно, что форматирование, используемое для ваших комментариев, может зависеть от вашей среды разработки (Visual studio, JavaDoc в Eclipse, …)

Что касается SCE, я предполагаю, что под этим вы подразумеваете следующее:

 bool b1;
b1 = somecomplicated_function(); // let me explain what this function does
bool b2 = false;
if (!b1) {                       // SCE : if first function call is already true,
                                 // no need to spend resources executing second function.
  b2 = someother_function();     // this function does something else
}

if (b1 || b2) {
...
}
 

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