Jump to content
php.lv forumi

vai leitot RETURN vai tomēr ne (diskusijas turpinājums)


Grey_Wolf

Recommended Posts

Jau pāris postus iepriekš rakstīju, ka ērtāk būtu izveidot jaunu diskusiju
pārnesu sarunu uz jaunu tēmu no lai nevedotos Oftopiks...

Piemēram, ja būs funkcija showPanel() - ar procedūras nozīmi, tad return šādā funkcijā nelikšu.

ir tā, ja tev pēķšņi ievajadzēsies noskaidrot vai tā funkcija nostrādājusi vai nē, tad
ja nebūs tas return, tad būs sarežģīti ( nosacīti) uztaisīt lai korekti veiktu pārbaudi, toties ja būs jau uzlikts return true/false, tad varēsī vairs nepievērst tai funkcijai uzmanību, bet veidot tikai pašu pārbaudi.
labais tonis nosaka, ka funkcijām jatgriež kaut kāda vērtība ( true/false/ xxx ), tieši tādēļ lai citi programmētāji varētu vairs nepārbaudīt tavu kodu ...

 

Link to comment
Share on other sites

  • Replies 149
  • Created
  • Last Reply

Top Posters In This Topic

Nav jēgas likt kaut ko atgriezt, ja tas nekur tālāk nav jāizmanto, bet vide automātiski paredz default atgriežamo vērtību. Ja funkcijā nav return, tad taču skaidrs, ka return value būs undefined. Kāpēc tas vēl īpaši jāpieraksta?

Link to comment
Share on other sites

ir tā, ja tev pēķšņi ievajadzēsies noskaidrot vai tā funkcija nostrādājusi vai nē, tad

ja nebūs tas return, tad būs sarežģīti ( nosacīti) uztaisīt lai korekti veiktu pārbaudi, toties ja būs jau uzlikts return true/false, tad varēsī vairs nepievērst tai funkcijai uzmanību, bet veidot tikai pašu pārbaudi.

Piemērs:
A={
  el:$('#somelement'),
  show:function(){
    this.el.show();
  }
};
//...
A.show();
Kāpēc, lai šeit show kaut ko atgrieztu?

labais tonis nosaka, ka funkcijām jatgriež kaut kāda vērtība ( true/false/ xxx ), tieši tādēļ lai citi programmētāji varētu vairs nepārbaudīt tavu kodu ...

Kā jau Kavacky minēja, defaultā tiek atgriezts udefined un, ja nekas cits nav nepieciešams, tad return nav nepieciešams. Edited by codez
Link to comment
Share on other sites

Gribēju piebilst, ka eksepšeni arī tika ieviesti kā aizvietotājs returnam.

 

Četri veidi. http://vpaste.net/HCfja

 

Eksepšeni, protams, ir lasāmāki un jaukāki. Arī, ar eksepšeniem ir mazāka iespēja sailenlī feilot. :)

Link to comment
Share on other sites

bet tad pusi koda sastāda try catch, man šādā gadījumā labāk patīk go pieeja, kad ir vairākas atgriežamās vērtības un pēc convention'iem pēdējā atgrieztā vērtība ir errors + kopā ar defer funkcijā resursu atbrīvošana ir daudz vienkāršāka nekā rakstīt try...catch...finally blokus

Edited by spainis
Link to comment
Share on other sites

Tur jau tā lieta, ka try-catch ir nepieciešams tikai tad kad ir special case. Tikai atšķirība ir tur, ka bez nekādiem try-catch un if'iem, `return 1` nebūs pamanīts, bet exceptions nograus visu sistēmu, kas ir labi.

Link to comment
Share on other sites

tas, ko return nespēj normāli realizēt ir kļūdas stāvokļa nodošana nestētiem izsaukumiem, piemēram:


function f1(){

throw new Exception();

}

function f2(){

f1();

}

function f3(){

f2();

}

function f4(){

f3();

f2();

}

 

try{

f4();

} catch(Exception $e){

showError();

}

Bez exceptioniem katrā funkcijā ir jāraksta kaudze ifu un ar return ir jānodod uz augšu arvien komplicētāki un sazarotāki kļūdu stāvokļi. Principā pat jāveido klase vai objekts priekš kļūdas stāvokļa nodošanas.
Link to comment
Share on other sites

Nu pie tāda tipa kļūdām, kad nav iespējams izlabot/noteikt stāvokli, ir jākrešo ar lielu blīkšķi un jāsalabo programma.

vienkāršā situācija - lietotājs pērk virtuālu preci.

$total=$price*$amount;
$account->decMoney($total);
$account->addItem($item, $amount);
$db->commit();
 

Gadījumā ar eksepšaniem, decMoney vai addItem izmetīs eksepšanu, ka trūkst nauda vai ka inventory ir pilns, bet savukārt front kontroleris, kurš izsauca doto actionu apstrādās šos eksepšanus un izvadīs attiecīgo kļūdu ziņojumu.

Gadījumā, ja to nedarītu ar ekcepšioneim, tas izskatītos šādi

$total=$price*$amount;
if ($account->isEnoughMoney($total)){
  $account->decMoney($total);
} else {
  $response->addError("Not enough money");
}if ($account->invetorySize()>=$account->itemsInInventory()+$ammount){
  $account->addItem($item, $amount);
} else {
  $response->addError("Inventory to small");
}
$db->commit();

Un šeit ir gadījums, kad katrā no metodēm ir iespējams tikai viens kļūdu gadījums, bet, ja nu ir vairāki, tad nāksies pievienot vēl veselu kaudzi validācijas.

Nemaz nerunājot par gadījumu, ka pēkšņi gribi izveidot funkciju $account objekta klasei, piemēram, givePresent($item), kura izmanto metodi addItem, bet kuru savukārt pašu var izsaukt. kļūdas stāvoklis no addItem par nepietiekamu inventorija izmēru būs jāsūta uz augšu līdz par vietai, kur izsauc givePresent.

Edited by codez
Link to comment
Share on other sites

marrtin, try un catch atrodas vienu reizi front kontrolerī. throw exception tieši tajā vietā, kur dotā tarbība tiek veikta.

Bet visi kontroleri, ajax pieprasījumi actioni, utt. ir īsi un konkrēti, neko nevalidē un nepārbauda lielākajā daļā gadījumu. Kopumā sanāk daudz, daudz īsāk, jo, piemēram, $account->decMoney tev aplikācijā var nākties izsaukt 10 vietās, tāpēc labāk, ka visa validācija ir pašā decMoney, savukārt kļūdas stāvoklis tiek tālāk nodots nevis ar return, bet ar exceptionu.

Edited by codez
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...