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

[Grey_Wolf]

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 ...

 

[Kavacky]

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?

[codez]

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 March 7, 2013 by codez

[daGrevis]

Lai noskaidrotu, ka funkcija nav izpidījusies pareizi — tam ir domāti eksepšeni.

[codez]

Lai noskaidrotu, ka funkcija nav izpidījusies pareizi — tam ir domāti eksepšeni.

Tieši tā, eksepšani ir daudz labāks kļūdu kontroles mehānisms, nekā neskaitāmi nestēti ifi un returni no returniem.

[v3rb0]

imho ja valoda neatgriež no f-jas pēdējās darbības rezultātu kā scala vai ruby, tad tā ar ir un ja nevajag, tad nevajag, labais tonis ir nerakstīt liekas rindas.

[daGrevis]

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. :)

[spainis]

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 March 7, 2013 by spainis

[daGrevis]

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.

[codez]

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.

[marrtins]

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.

[codez]

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 March 7, 2013 by codez

[marrtins]

Nu bet Tu tak man demonstrē programmas stāvokli, kas ir zināms - nav nafdas vai nav daudzums.

Un tagad uzraksti to pašu ar try catch - tāds pats blāķis vien sanāks.

[codez]

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 March 7, 2013 by codez

[marrtins]

$account->decMoney($total); - raise exeption. Noķer kontroleris. Ko man darīt, ja es gribu turpat pamēģināt citu maksāšanas metodi vai iešķiet userim soda punktus? Uzreiz tas try catch pārvēršas par tiem pašiem if else