Dotaz: Můžu vložit return do podmínky když není v žádném cyklu?

[Host]

Ahoj, můžu do podmínky vložit return, aby se již neprovedl kód pod podmínkou pokud je ta podmínka splněna? Podmínka není v žádném cyklu. Díky

if ($url == 'foo'){
  $a = 10;
  return;
}

---

---

Odpovědi

[MadCatX]

return slouží pro návrat z funkce, nikoliv pro ukončení cyklu. Pokud je ten kód součástí funkce, return tam použít můžeš.

[NN]

Mi Muzes pouzit 'exit' pokud tato moznost v jazyce existuje.

[Petr Šobáň]

Je to blbě, pokud chceš při splněné podmínce a při nesplněné provádět dva rozdílné kody tak se používá if - else.

if(x>0) printf("Cislo je vetsi nez nula.\n");
else    printf("Cislo neni vetsi nez nula.\n");

printf("A pokračujem společným kodem.\n")

[.]

Možná chce “aby se již neprovedl kód pod podmínkou pokud je ta podmínka splněna”

[Petr Šobáň]

Však ano .....

if(x>0) printf("Cislo je vetsi nez nula.\n");
else    printf("Cislo neni vetsi nez nula.\n");
 
return;

Podle mě je to takto přehlednější, ale samozřejmě každý má jiné zvyky.

[Michal Kubeček]

Spíš jde o tohle:

void napi_consume_skb(struct sk_buff *skb, int budget)
{
        if (unlikely(!skb))
                return;

        /* dalších 20 řádků vlastního kódu funkce */
}

Samozřejmě můžete celý ten zbytek těla funkce, tj. celou její podstatu, odsadit a dát do else větve (nebo spíš rovnou otočit tu podmínku), ale čitelnosti to rozhodně neprospěje.

[rastos]

Ja som veľmi konzervatívny a preferujem aby mala funkcia len jeden return.

[Petr Šobáň]

Taky preferuji jeden return, a pouze při závažné chybě kdy se nemůže pokračovat ukončené kdekoliv pomocí exit.

[jekub]

vždyť má

[lertimir]

Jak píše MadCadX, return je návrat z procedury/funkce. Dokonce se taková struktura poměrně často i používá. V testu if se posoudí, jestli parametry funkce, nebo jiná data, jsou chybně. Pokud jsou, tak nemá smysl ve funkci dále pokračovat, ošetří se chybový návratový stav a returnem se vrací.

[ydenda]

Pár let v automotive mě vychovalo tak, aby funkce/metoda měla právě jeden vstupní bod a právě jeden výstupní bod. Kdyby nic jinýho, zvyšuje to přehlednost. Je to jedno z méně hloupých Lint/MISRA pravidel.

[Tomáš Bžatek]

To tvrzení, že to zvyšuje přehlednost, vypadá bez dalšího vysvětlení dost nepravděpodobně. Můžete to nějak rozvést? Jenom když si představím klasický příklad, že je potřeba na začátku funkce/metody otestovat vstupní hodnoty – pokud povolím více výstupních bodů, po každém neúspěšném testu vyskočím z funkce, pokud je test úspěšný, pokračuju v těle funkce. Pokud to budu chtít přepsat na jediný výstupní bod, vznikne z toho kaskáda do sebe zanořených ifů…

[Michal Kubeček]

No, pořád ještě je tu možnost dát si na konec funkce label a místo returnů sekat goto na něj. :-)

[lertimir]

To jsi mi připomněl aritmetické if ve FORTRANu

IF proměnná negativ,zero,positive

se třemi labely. kdy kód za žádné podmínky nemusel pokračovat za IF. s oblibou jsem s tím na VŠ provokoval.

[Michal Kubeček]

Dokonalý chaos ovšem přinášejí interpretované jazyky. Např. "oblíbené"

  ON <expr> GOTO <num> [, <num>... ]

v řadě dialektů BASICu a v některých dokonce

  GOTO <expr>

Z toho se teoretikům programovacích stylů ježily chlupy i tam, kde netušili, že nějaké mají. :-)

[ydenda]

Abych se vyhnul zamotání se do detailů, narážka na vstupní body metody se týkala především GOTO (všichni dlouho zakazují použití, ale nikdo ho z překladače dosud nevyhodil :) ) nikoliv argumentů metody. Pokud je vstupních argumentů metody mnoho, odvolal bych se na designera... případně je testoval v separátní metodě. Na vysvětlenou dodám, že reset procesoru nepovažuji za výstupní bod. Přeci jen, pokud kontroluji nějaké proměnné s vyšším stupněm zabezpečení, v případě nesrovnalostí, volám reset OS - pro zajištění bezpečí osob/majetku. V případě, že je porucha fatální, a handling by mi navrátil kontrolu, skočím pro jistotu do nekonečné smyčky (z hlediska designu to snad nikdo nepovažuje za výstupní bod :)). Teď však k dlužnému vysvětlení: Dříve jsem používal returnů v metodách několik, avšak v zaměstnání jsem přišel na to, že je fajn, když se dodržuje dohodnutá štábní kultura a navíc když ji hlídá nějaký tool, např (sp)lint apod. Ten kritizuje spoustu maličkostí, ale u returnu jsem musel uznat, že je to opodstatněné varování. Představte si, že máte "povinnost/šanci" kontrolovat po kolegovi kód před každým mergem. Pak je reviewer rád za to, že 50 lidí píše jakš-takš uniformní kód bez ohledu na národnost. K tomu pro mě, bez pochyby, patří i počet returnů v metodě. Odpadá pak potřeba počítat, jestli ta či ona metoda měla 3 nebo 6 returnů -> měla prostě jenom jeden. Chápu, že to v někom snadno vyvolá pocit, že se snažím udělat return zbytečným, když bude vždy a pouze před poslední závorkou. Pro PC platformu bych to asi zvládnul, ale práce v automotive na mě měla eviděntně vliv... V zásadě je více vstupních/výstupních bodů metody noční můrou spíše pro designery než pro pisatele kódu, ale neměl by být pisatel tak trochu i designerem? Snad jsem Vám odpověděl.

PS OP těsně před returnem nastavuje nějakou statickou nebo globální proměnnou - to taky musí bejt pošušňáníčko pro unit testy nebo pro hledače závislostí :)

[Michal Kubeček]

Snad jsem Vám odpověděl.

Mám-li být upřímný, za sebe musím říct, že moc ne. Co se týká review kódu, osobně mnohem radši na začátku funkce uvidím

        mp = kzalloc(sizeof(u32) * RTAX_MAX, GFP_KERNEL);
        if (unlikely(!mp))
                return -ENOMEM;

než aby tam bylo formální "goto out" a já se musel ještě podívat dolů, jestli se v tom případě nedělá něco dalšího. To má naopak dobrý smysl, pokud na konci bude něco jako

err:
        kfree(mp);
        return -EINVAL;
}

a bude se tam skákat z víc různých míst. Nebo třeba u kaskád jako tady

[Filip Jirsák]

Z vaší odpovědi jsem se dozvěděl, že je dobré dodržovat štábní kulturu, s čímž souhlasím. Nicméně nemám pocit, že by vysvětlovala, jak může pravidlo jediného výstupního bodu zpřehledňovat kód.

Abychom se bavili o něčem konkrétním – primitivní funkce pro kopírování souborů bude s několika výstupními body vypadat nějak takhle:

void copy(source, target) {
  if (!file_exists(source)) {
    throw "Zdrojový soubor neexistuje.";
  }
  if (!is_dir(source)) {
    throw "Zdroj nemůže být adresář.";
  }
  if (!is_readable(source)) {
    throw "Zdrojový soubor nelze číst.";
  }
  if (!is_dir(target)) {
    throw "Cíl nemůže být adresář.";
  }

  parent = parent_dir(target);
  if (!file_exists(parent)) {
    throw "Neexistuje adresář pro cílový soubor.";
  }
  if (exists(target)) {
    throw "Cílový soubor již existuje.";
  }
  if (!is_writable(parent)) {
    throw "Do cílového adresáře nelze zapisovat.";
  }
  if (get_free_space(parent) < get_file_size(source)) {
    throw "V cílovém adresáři není dost volného místa.";
  }

  buffer, offset;
  do {
    buffer = read(source, offset, size(buffer));
    write(target, offset, buffer);
    offset += size(buffer);
  } while(size(buffer) > 0);
}

Když to přepíšu na jediný výstupní bod, dostanu:

void copy(source, target) {
  error = null;
  if (file_exists(source)) {
    if (is_dir(source)) {
      if (is_readable(source)) {
        parent = parent_dir(target);
        if (file_exists(parent)) {
          if (is_dir(target)) {
            if (is_writable(parent)) {
              if (!exists(target)) {
                if (get_free_space(parent) >= get_file_size(source)) {
                  buffer, offset;
                  do {
                    buffer = read(source, offset, size(buffer));
                    write(target, offset, buffer);
                    offset += size(buffer);
                  } while(size(buffer) > 0);
                } else {
                  error = "V cílovém adresáři není dost volného místa.";
                }
              } else {
                error = "Cílový soubor již existuje.";
              }
            } else {
              error = "Do cílového adresáře nelze zapisovat.";
            }
          } else {
            error = "Cíl nemůže být adresář.";
          }
      } else {
          error = "Neexistuje adresář pro cílový soubor.";
        }
      } else {
        error = "Zdrojový soubor nelze číst.";
      }
    } else {
      error = "Zdroj nemůže být adresář.";
    }
  } else {
    error = "Zdrojový soubor neexistuje.";
  }
  throw error;
}

Pro mne je tedy ten druhý kód daleko nepřehlednější, a porušuje například jednu velmi dobrou zásadu omezující počet vnoření bloků. Nebo jak byste ten kód přepsal na jediný výstupní bod bez těch vnořených ifů? Počet vnoření by se samozřejmě dal zredukovat sloučením několika testů do jednoho a vytknutím do samostatné funkce, ale to neřeší princip problému.

Možná je rozdíl v programování triviálních funkcí přímo nad procesorem, kde máte jasně definované podmínky běhu, a pokud se náhodou dostanete mimo ně, zastavíte procesor a nějaký watchdog rozsvítí červenou kontrolku, že je všechno špatně (a mimochodem reset procesoru podle mne je výstupní bod, je to obdoba vyhození výjimky ve vyšších programovacích jazycích a způsob, jakým se ukončí provádění dané funkce). A v programování pro počítače, tablety, mobily, televize apod., kde uživatel pracuje přímo s programem, podmínky jsou velmi různorodé a každý očekává, že se z nečekaných situací dokáže program zotavit.