Ініціалізація змінних у операторі “якщо”

Я читав, що в C ++ 17 ми можемо ініціалізувати змінні в ifтаких операторах

if (int length = 2; length == 2)
    //execute something

Замість

int length = 2;
if (length == 2)
    //do something

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

Чи є якась перевага використання цієї функції, крім скорочення коду?

Це обмежує сферу lengthдоif одного. Отже, ви отримуєте ті самі переваги, які ми отримували спочатку, коли нам дозволяли писати

for(int i = 0; i < ... ; ++i) {
   // ...
}

Замість змінної тече

int i;
for(i = 0; i < ... ; ++i) {
   // ...
}

Недовговічні змінні краще з кількох причин. Але назвати пару:

1. Чим коротше щось живе, тим менше речей потрібно мати на увазі при читанні не пов’язаних між собою рядків коду. Якщо iне існує поза циклом або ifтвердженням, тоді нам не потрібно зважати на його значення поза ними. Також нам не потрібно турбуватися, що його значення буде взаємодіяти з іншими частинами програми, що виходять за межі передбачуваного обсягу (що може статися, якщо iвище повторно використати в іншому циклі). Це полегшує читання коду та міркування про нього.

2. Якщо змінна містить ресурс, то цей ресурс тепер зберігається протягом найкоротшого періоду. І це без сторонніх фігурних дужок. Також стало ясно, що ресурс пов’язаний лише з ifодним. Розгляньте це як спонукальний приклад

   if(std::lock_guard _(mtx); guarded_thing.is_ready()) {
   }
   

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

Чи є якась перевага використання цієї функції, крім скорочення коду?

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

Зверніть увагу, що ви вже можете виконати ініціалізацію та розгалуження результату в pre-C ++ 17:

int *get(); // returns nullptr under some condition

if (int *ptr = get())
    doStuff();

Це залежить від особистої думки, але ви можете вважати чіткий стан більш читабельним:

if (int *ptr = get(); ptr != nullptr)
    doStuff();

Окрім того, аргументувати читабельність функції, посилаючись на те, що люди до неї не звикли, небезпечно. Люди в якийсь момент не звикли до розумних покажчиків, але все-таки ми всі сьогодні погоджуємось (думаю), що добре, що вони там.

Нова форма оператора if має багато застосувань.

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

Відкрийте стандартну пропозицію для оператора If з ініціалізатором

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

Сподіваюся, це допоможе!

З метою мінімізації обсягу змінних існує ідіома, яка визначає ресурс, лише якщо він дійсний при створенні (наприклад, об'єкти потоку файлів ):

if(auto file = std::ifstream("filename"))
{
    // use file here
}
else
{
    // complain about errors here
}

// The identifier `file` does not pollute the wider scope

Іноді ви хочете мати можливість змінити логіку цього тесту, щоб зробити збій основним реченням, а дійсний ресурс - elseреченням. Раніше це було неможливо. Але тепер ми можемо зробити:

if(auto file = std::ifstream("filename"); !file)
{
    // complain about errors here
}
else
{
    // use file here
}

Прикладом може бути створення винятку:

if(auto file = std::ifstream(filename); !file)
    throw std::runtime_error(std::strerror(errno));
else
{
    // use file here
}

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

Це особливо корисно для логічних подій. Розглянемо цей приклад:

char op = '-';
if (op != '-' && op != '+' && op != '*' && op != '/') {
    std::cerr << "bad stuff\n";
}

Здається, трохи грубо. Якщо ви не знайомі з OR, ANDнегаціями, можливо, вам доведеться зробити паузу і подумати над цією логікою - яка, як правило, поганий дизайн. За допомогою if-initializationви можете додати виразності.

char op = '-';
if (bool op_valid = (op == '-') || (op == '+') || (op == '*') || (op == '/'); !op_valid) {
    std::cerr << "bad stuff\n";
} 

названу змінну також можна повторно використовувати всередині if. Наприклад:

if (double distance = std::sqrt(a * a + b * b); distance < 0.5){
    std::cerr << distance << " is too small\n";
}

Це чудово, особливо з огляду на те, що змінна має масштаб і тому не забруднює простір згодом.

Це продовження існуючої функції, яка допомагає читати, на мій досвід.

if (auto* ptr = get_something()) {
}

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

Але що, якщо ми говоримо про те, що не перетворюється на boolтакий шлях?

if (auto itr = find(bob)) {
}

Це не працює. Але за допомогою цієї нової функції ми можемо:

if (auto itr = find(bob); itr != end()) {
}

Додайте речення "коли ця ініціалізація дійсна".

По суті, це дає нам набір лексем, які означають "ініціалізувати якийсь вираз, і коли він дійсний, ввести якийсь код. Коли він не дійсний, відкиньте його".

Починати фокус із тестуванням покажчика було ідіоматично ще з C ++ 98. Отримавши це, це продовження є природним.