якщо твердження - оцінка короткого замикання проти читабельності

Іноді 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
}

Це має переваги у тому, що їх легко зрозуміти, застосувати у всіх випадках та мати поведінку короткого замикання.

Це було моє початкове рішення: Хорошим шаблоном у викликах методів та тілах циклу є таке:

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

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

// do stuff

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

Я схильний розбивати умови на кілька рядків, тобто:

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

Навіть коли ви маєте справу з кількома операторами (&&), вам просто потрібно просувати відступ за допомогою кожної пари дужок. SCE все ще працює - немає необхідності використовувати змінні. Написання коду таким чином зробило його набагато доступнішим для мене вже багато років. Більш складний приклад:

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

Якщо у вас довгі ланцюги умов і що зберегти деякі короткі замикання, ви можете використовувати тимчасові змінні, щоб поєднати кілька умов. На вашому прикладі це можна було б зробити, наприклад

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

Якщо у вас є компілятор, що підтримує C ++ 11, ви можете використовувати лямбда-вирази для об'єднання виразів у функції, подібні до вищезазначених:

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

if (e() && 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. b1 == trueТоді Ff b2не буде оцінено (SCE). АлеOtherComplicatedFunctionCall() вже запущений.

Якщо b2ніде не використовується, компілятор може бути досить розумним, щоб вбудувати виклик функції всередині if, якщо функція не має спостережуваних побічних ефектів.

2) Яка найкраща практика в такій ситуації? Чи це єдина можливість (коли я хочу SCE) мати все, що мені потрібно, безпосередньо всередині if і "просто відформатувати, щоб це було якомога читабельніше"?

Це залежить. Вам потрібно OtherComplicatedFunctionCall() запускати через побічні ефекти або показник продуктивності функції мінімальний, тоді вам слід використовувати другий підхід для читабельності. В іншому випадку дотримуйтесь SCE через перший підхід.

Ще одна можливість того, що коротке замикання і має умови в одному місці:

bool (* conditions [])()= {&a, &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>& X_axis, std::vector<int>& 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) {
...
}

Читаність необхідна, якщо ви працюєте в компанії, і ваш код буде прочитаний кимось іншим. Якщо ви пишете програму для себе, це залежить від вас, якщо ви хочете пожертвувати продуктивністю заради зрозумілого коду.