Upotreba return u funkcijama - programerski stilovi
Davno kad sam na faxu imao Osnove programiranja insistiralo se da u funkciji sme da bude samo jedan return, na kraju funkcije. Medjutim sad dok sam pisao neki kod shvatio sam da ja to uopste vise ne postujem i da mi je mnogo pregledniji kod kad sve returne uradim sto pre (manje identacije, manje {} blokova)
Odnosno cini mi se da je to pravilo potpuna besmilica u modernim editorima koji imaju highlight search rezultata, pa je lako videti sve izlazne tacke iz funkcije, zapravo mnogo lakse nego traziti gde ce skociti neki break; Znaci pricam o: PHP kôd:
PHP kôd:
Ovo je php (ili javascript) u primeru, ali pitanje se odnosi na sve jezike... |
То су више правила из Фортранских дана када си могао да имаш не само више излаза из функције (и то на различита места!) већ и разне улазе.
|
Preporučujem ti da pročitaš "Code Complete" knjigu ako već nisi. Tamo možeš naći slične nedoumice i mnogo pravih korisnih saveta :)
U ovakvom primeru meni je svakako bolji prvi način i ja ga skoro uvek koristim, ali postoje nekada situacije kada koristim i drugi, pa ću dati primere... Problem kod drugog primera je što se vrlo lako da desiti da odeš u duboko ugnježdavanje, a ovakav stil kao u prvom primeru baš to sprečava. Nepotrebno je praviti taj drugi else blok u kome će biti iskodirana cela procedura, jer uglavnom unutar tog else bloka će stajati još neki if i za čas ti ode početak linije na sredinu monitora. Generalno, što imaš manje ugnježdenih blokova, to je kod čitljiviji. Mislim da je Ričard Stalman rekao da je dobar kod onaj koji nema više od 3 ugnježdena bloka. Međutim, drugi stil bih koristio kada zaista trebam neke realne podatke stavim u tu promenjivu $status. Tvoj primer je dosta jednostavan, ali recimo, ovo je sada izmišljeni primer kada je potrebno pratiti takav stil: PHP kôd:
|
^ +1
kao da sam ja pisao, ali bolje objasnjeno :) |
Ja se ne slažem za ugnježdavanje. Ta pravila su možda važila u vreme 14-inčnih monitora i u vreme kada se štedela memorija. Danas, kad skoro svi imaju 22-inča ili veće sa HD rezolucijom stvarno ne vidim problem da imam normalan if - else sa vitičastim zagradama i kada imam samo jednu liniju koda. Preglednije je i lako mogu da ispišem neki tekst za debug ili da dodam još jednu linju koda u blok po potrebi.
|
Kôd:
if($a == 'nesto') Kôd:
if ($a=='nesto') return false; |
ok, nije to sto sam izostavio par zagrada oko if bila poenta, neko voli da ih pise, neko ne... pricao sam o zahtevu da se koristi samo jedan return, radi preglednosti koda...
Zapravo, cela stvar mi je pala na pamet jer sam nedavno procitao na minecraft blogu text u kome autor pominje kako su mu na nekom intervjuu zamerili sto nije "skolovani programer", pa zato ne vodi dovoljno racuna o konvencijama i best-practices savetima (koje bi valjda naucio na faxu da nije samouk)... malo mi je to zazvucalo kao bull****, koliko god njihovi fakulteti bili bolji od nasih, jer ono sto su mene ucili na faxu pre 15 godina, a skolovao sam se za programera, nije bas toliko krucijalno, a mnogo toga mislim da nije ni tacno, bar ne vise (kao recimo ovo za jedan return) |
Citat:
Trudim se da odmah return-ujem ako to pojednostavljuje ostatak koda. Inače bi imao dodatna ugnježivanja ili administraciju result varijabli. To znači da mogu da mi se dese i jedan i drugi slučaj u istoj funkciji, ali ne mislim da je to loše. Ne jednom sam koristio goto iz istog razloga... od nedavno stavljam komentar // kacam rasan :) Osim naravno u situacijama kada je očigledno o čemu se radi (npr. @salebab-ov primer). Ja bih ga napisao ovako, prvo proveravam fail situacije i tako ih mentalno "brišem" i manje gledam gore-dole i uparujem zagrade :) PHP kôd:
|
Slazem se sa @dinosaurus, mislim da je to zastareo coding standard...
U svakom slucaju @degojs - mrzim kad neko tako napise if() uslov. Po nekom mom standardu pisem ga ovako UVEK ovako HTML kôd:
if($a == 'nesto'){ |
^ i ja to radim, ali više praktična stvar: možeš da staviš breakpoint na return :)
|
Vreme je GMT +2. Trenutno vreme je 02:10. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.