powinniśmy unikać/minimalizować użycie instrukcji return w javascript flow control

Question

W obecnym oprogramowaniu, nad którym pracuję, widzę ten wzorzec dość szeroko i wydaje się, że starają się unikać instrukcji return w jak największym stopniu. Nawet w niektórych miejscach w kodzie jest to niemal ekstremalne.

Od dłuższego czasu słyszałem, że zwroty powinny być zminimalizowane lub unikane, ale nie pamiętam (ani nie szukam) dokładnego powodu ani źródła tego spostrzeżenia. Uważam, że było to spowodowane pewną konsekwencją wydajności w niektórych PL.

Ja osobiście nie stosuję się do tego, ponieważ nie tworzy on kodu, który można odczytać, ale zważywszy na wątpliwości, jestem ciekawy, czy użycie tego wzoru ma swoje zalety w javascript pod względem wydajności.

if (err) { 
    if (err.message) { 
     message = err.message; 
    } else { 
     if (err.errorCode) { 
      message = err.errorCode; 
     } else { 
      message = "Unknown error"; 
     } 
    } 
} else { 
    message = "Unknown error."; 
} 
deferred.reject(message); 

Gdybym miał decydować, to bym swobodnie korzystać z instrukcji return, aby zakończyć sekwencję tak:

if(!err || (!err.message && !err.errorCode)){ 
    deferred.reject("Unknown error."); 
    return; 
} 

if(err.message){ 
    deferred.reject(err.message); 
    return; 
} 

if(err.errorCode){ 
    deferred.reject(err.errorCode); 
} 

Czy istnieją zalety w pierwszym wzór nad drugim?

Answer 1

Twój przykładowy kod również posiada pseudonim - choinka, aw prawdziwych projektach bardzo ciężko jest wspierać taki kod.
Na przykład potrzebujesz dodać kolejny warunek - wstawisz kolejny blok if wewnątrz i tak dalej i tak dalej i będzie to koszmar ... a w rezultacie będziesz miał okropne drzewo ...

Jako alternatywę można coś takiego:

if (err) { 
    if (err.message) { 
     return err.message; 
    } 
    if (err.errorCode) { 
     return err.errorCode; 
    } 
} 
return "Unknown error."; 

Taki kod wygląda prościej, prawda?
Więc naprawdę wierzę, że ma to sens w użyciu dla takich celów return.

ALE, myślę, że głównym punktem jest tutaj - nie tracić konsystencji! W naszym przykładzie, zawsze zwraca wynik w samego typu danych iz samej logiki biznesowej, i na przykład:

if (err) { 
    if (err.message) { 
     return err; 
    } 
    // Here some stuff... 
    // Few lines of code... 
    // 
    return -1; 
} 
// Another code... 
// 
if (!user) { 
    return null; 
} 
// And somewhere in the end on anothere scrollin screen 
//  
return user.email; 

tym przykładzie zwraca object lub number lub null lub string - i jest to kolejny koszmar ...
A w prawdziwych projektach z dużymi funkcjami, bardzo łatwo jest uzyskać taki kod ze względu na wiele zwrotów ...
Więc tutaj lepiej mieć mniejszą liczbę zwrotów, znowu dlatego, że jest łatwy w obsłudze ...