Inicjalizacja zmiennych w instrukcji „if”

Czytałem, że w C ++ 17 możemy inicjalizować zmienne w iftakich instrukcjach

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

Zamiast

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

Mimo że jest krótszy, wpływa na czytelność kodu (szczególnie dla osób, które nie znają tej nowej funkcji), co, jak sądzę, jest złą praktyką kodowania w przypadku tworzenia dużego oprogramowania.

Czy korzystanie z tej funkcji ma inne zalety niż skrócenie kodu?

Ogranicza zakres lengthdo ifsamego. Otrzymujesz więc te same korzyści, jakie otrzymaliśmy, kiedy pozwolono nam pisać

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

Zamiast przecieku zmiennej

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

Zmienne krótkotrwałe są lepsze z kilku powodów. Ale żeby wymienić kilka:

1. Im krócej coś żyje, tym mniej rzeczy musisz pamiętać podczas czytania niepowiązanych ze sobą wierszy kodu. Jeśli inie istnieje poza pętlą lub ifinstrukcją, nie musimy przejmować się jego wartością poza nimi. Nie musimy też martwić się, że jego wartość będzie oddziaływać z innymi częściami programu, które są poza jego zamierzonym zakresem (co może się zdarzyć, jeśli ipowyższe zostanie ponownie użyte w innej pętli). Ułatwia śledzenie kodu i uzasadnienie.

2. Jeśli zmienna przechowuje zasób, to jest on teraz przechowywany przez najkrótszy możliwy okres. I to bez obcych kręconych szelek. Wyjaśniono również, że zasób jest powiązany z ifsamym. Potraktuj to jako motywujący przykład

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

Jeśli Twoi koledzy nie są świadomi tej funkcji, naucz ich! Uspokajanie programistów, którzy nie chcą się uczyć, to kiepska wymówka, aby unikać funkcji.

Czy korzystanie z tej funkcji ma inne zalety niż skrócenie kodu?

Zmniejszasz zakres zmiennej. Ma to sens i zwiększa czytelność, ponieważ wzmacnia lokalizację identyfikatorów, o których musisz się zastanowić. Zgadzam się, że ifnależy unikać długich instrukcji init w instrukcjach, ale w przypadku krótkich rzeczy jest w porządku.

Zauważ, że możesz już wykonać inicjalizację i rozgałęzienie wyniku w wersji przed C ++ 17:

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

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

To zależy od osobistej opinii, ale możesz uznać wyraźny warunek za bardziej czytelny:

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

Poza tym argumentowanie przeciwko czytelności funkcji poprzez odwoływanie się do faktu, że ludzie nie są do niej przyzwyczajeni, jest niebezpieczne. W pewnym momencie ludzie nie byli przyzwyczajeni do mądrych wskazówek, ale dzisiaj wszyscy zgadzamy się (chyba), że dobrze, że tam są.

Nowa forma instrukcji if ma wiele zastosowań.

Obecnie inicjator jest zadeklarowany przed instrukcją i wyciekł do zakresu otoczenia lub jest używany jawny zakres. Dzięki nowej formie taki kod można napisać bardziej zwięźle, a ulepszona kontrola zakresu sprawia, że ​​niektóre niegdyś podatne na błędy konstrukcje są nieco bardziej niezawodne.

Otwórz standardową propozycję instrukcji If z inicjatorem

Podsumowując, ta instrukcja upraszcza typowe wzorce kodu i pomaga użytkownikom zachować ścisłe zakresy.

Mam nadzieję, że to pomoże!

W celu zminimalizowania zakresu zmiennych istnieje idiom, który definiuje zasób tylko wtedy, gdy jest ważny w momencie tworzenia (na przykład obiekty strumieni plików ):

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

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

Czasami chcesz mieć możliwość odwrócenia logiki tego testu, aby błąd stał się klauzulą ​​podstawową, a prawidłowy zasób elseklauzulą. Wcześniej nie było to możliwe. Ale teraz możemy zrobić:

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

Przykładem może być zgłoszenie wyjątku:

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

Niektórzy ludzie lubią kodować tak, aby funkcja przerywała działanie wcześniej w przypadku błędu lub w inny sposób postępuje. Ten idiom fizycznie stawia logikę abortowania ponad logiką kontynuacji, którą niektórzy ludzie mogą uznać za bardziej naturalną.

Jest to szczególnie przydatne w przypadku zdarzeń logicznych. Rozważmy ten przykład:

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

Wydaje się trochę szorstkie. Jeśli nie jesteś bardzo zaznajomiony z OR, ANDnegacjami, być może będziesz musiał zatrzymać się i pomyśleć o tej logice - która jest ogólnie kiepskim projektem. Dzięki if-initializationmożesz dodać wyrazistości.

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

nazwana zmienna może być ponownie użyta wewnątrz iftoo. Na przykład:

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

Jest to świetne, zwłaszcza biorąc pod uwagę, że zmienna ma określony zakres i dlatego nie zanieczyszcza później przestrzeni.

Jest to rozszerzenie istniejącej funkcji, która zwiększa czytelność w moim doświadczeniu.

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

Tutaj oboje tworzymy zmienną ptri sprawdzamy, czy nie jest zerowa. Zakres ptrjest ograniczony do miejsca, w którym jest ważny. O wiele łatwiej jest przekonać siebie, że każde użycie ptrjest słuszne.

Ale co, jeśli mówimy o czymś, co nie przekształca się w boolten sposób?

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

To nie działa. Ale dzięki tej nowej funkcji możemy:

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

Dodaj klauzulę mówiącą „kiedy ta inicjalizacja jest prawidłowa”.

W istocie daje nam to zestaw tokenów, które oznaczają „zainicjuj jakieś wyrażenie, a kiedy będzie poprawne, wykonaj jakiś kod. Jeśli nie jest poprawne, odrzuć je”.

Od czasu C ++ 98 było idiomatyczne wykonanie sztuczki testującej wskaźnik. Kiedy już to zaakceptujesz, to rozszerzenie jest naturalne.