funzioni anonime considerate dannose?

Question

Più mi dedico a javascript, più rifletto sulle conseguenze di determinate decisioni di progettazione e pratiche incoraggiate. In questo caso, sto osservando funzioni anonime, una funzionalità che non è solo fornita da JavaScript, ma che vedo fortemente utilizzata.

Credo che siamo tutti d'accordo sui seguenti fatti:

• la mente umana non si occupa più di 7 più meno di due entità (Miller's law)
• profonda rientranza è considerato bad programming practice, e sottolinea in generale a problemi di progettazione se si indentano più di tre o quattro livelli. Questo si estende alle entità nidificate, ed è ben presentato nella voce Zen di Python "Flat is better than nested."
• l'idea di avere un nome di funzione è sia di riferimento che di facile documentazione dell'attività che esegue. Sappiamo, o possiamo aspettarci, che funzione fa removeListEntry(). Il codice chiaro e autodocumentante è importante per il debug e la leggibilità.

Mentre le funzioni anonime sembrano essere una funzionalità molto carina, il suo uso porta a una progettazione del codice profondamente annidata. Il codice è veloce da scrivere, ma difficile da leggere. Invece di essere costretto a inventare un contesto nominato per una funzionalità e ad appiattire la gerarchia di oggetti callable, incoraggia un "go deep level", spingendo il tuo stack di cervello e traboccando rapidamente la regola 7 +/- 2. Un concetto simile è espresso in "About Face" di Alan Cooper, citando liberamente "le persone non capiscono le gerarchie". Come programmatori comprendiamo le gerarchie, ma la nostra biologia limita ancora la nostra comprensione del nidificazione profonda.

Mi piacerebbe sentirti su questo punto. Le funzioni anonime dovrebbero essere considerate dannose, un apparente zucchero sintattico apparente che in seguito si trova in sale o addirittura veleno per topi?

CW in quanto non esiste una risposta corretta.

Answer 1

Per come la vedo io, il problema che stai affrontando non sono funzioni anonime, piuttosto una riluttanza a scomporre la funzionalità in unità utili e riutilizzabili. Il che è interessante, perché è più facile riutilizzare la funzionalità in lingue con funzioni di prima classe (e, necessariamente, funzioni anonime) rispetto alle lingue senza.

Se nel codice sono presenti molte funzioni anonime profondamente annidate, suggerirei che potrebbero esserci molte funzionalità comuni che possono essere scomposte in funzioni denominate di ordine superiore (cioè funzioni che prendono o restituiscono (" build ") altre funzioni). Anche le "semplici" trasformazioni delle funzioni esistenti dovrebbero avere un nome se vengono usate spesso. Questo è solo il principio SECCO.

Answer 2

Penso che le chiusure abbiano enormi vantaggi che non dovrebbero essere trascurati. Ad esempio, Apple sfrutta i "blocchi" (chiusure per C) con GCD per fornire un multithreading davvero semplice - non è necessario configurare le strutture di contesto e può semplicemente fare riferimento alle variabili per nome poiché sono nel campo di applicazione.

Penso che un problema più grande con Javascript sia che non ha scope di blocco (i blocchi in questo caso si riferiscono al codice in parentesi graffe, come un'istruzione if). Ciò può portare a enormi complicazioni, costringendo i programmatori a utilizzare chiusure inutili per aggirare questo limite di progettazione di Javascript.

Answer 3

Le funzioni anonime sono più utili dal punto di vista funzionale che dannose in modo leggibile. Penso che se si formatta il codice abbastanza bene, non si dovrebbe avere un problema. Non ho problemi con questo, e sono sicuro di non poter gestire 7 elementi, figuriamoci 7 + 2 :)

Answer 4

In realtà, le gerarchie aiutano a superare la regola 7 +/- 2 allo stesso modo di OOP lo fa. Quando scrivi o leggi un corso, leggi il suo contenuto e nulla del codice esterno in modo che tu abbia a che fare con una porzione relativamente piccola di entità. Quando guardi le gerarchie di classi, non guardi dentro di loro, significa che di nuovo hai a che fare con un piccolo numero di entità.

Lo stesso se vero per le funzioni annidate. Dividendo il tuo codice in più livelli di gerarchia, tieni ogni livello abbastanza piccolo da poter essere compreso dal cervello umano.

Le chiusure (o funzioni anonime) aiutano solo a suddividere il codice in un modo leggermente diverso rispetto a quello di OOP, ma in realtà non creano gerarchie.Sono qui per aiutarti a eseguire il tuo codice nel contesto di un altro blocco di codice. In C++ o Java devi creare una classe per questo, nella funzione JavaScript è sufficiente. Certo, la classe standalone è più facile da capire in quanto è semplicemente più semplice per gli umani guardarla come se fosse un blocco autonomo. La funzione sembra essere di dimensioni molto più piccole e il cervello a volte pensa di poterlo comprendere e di codificarlo allo stesso tempo, che di solito è una cattiva idea. Ma puoi allenare il tuo cervello a non farlo :)

Quindi no, non penso che le funzioni anonime siano dannose, devi solo imparare ad affrontarle, come hai imparato ad affrontare le lezioni.

Answer 5

Chi ha mai avuto l'idea di richiedere che le funzioni siano associate agli identificatori, ha fatto sì che ogni programmatore fosse un disservizio. Se non hai mai fatto una programmazione funzionale e non hai familiarità con le funzioni e sei a tuo agio con le funzioni di prima classe, non sei un vero programmatore.

In effetti, per contrastare la tua stessa argomentazione, vorrei arrivare fino a considerare le funzioni legate ai nomi (globali) come dannose! Controlla Crockford's article about private and public members e scopri di più.

Answer 6

Penso anche che le funzioni anonime (nelle ultime lingue spesso definite come chiusure) hanno grandi vantaggi e rendono il codice spesso più leggibile e più breve. A volte sto diventando pazzo quando devo lavorare con Java (dove le chiusure non sono caratteristiche linguistiche di prima classe).

Se il problema è costituito da indentazione e troppe variabili funzione incapsulate, è necessario ridefinire il codice per renderlo più modulare e leggibile.

Per quanto riguarda il java-script, penso che le variabili di funzione siano piuttosto brutte e rendono il codice ingombra (la funzione incapsulata (...) {} stringa rende il codice java-script spesso meno leggibile). Ad esempio preferisco di gran lunga la sintassi di chiusura di groovy ('{}' e '->' caratteri).

Answer 7

In modo divertente, JavaScript vi permetterà Nome Funzioni "anonimi":

function f(x) { 
    return function add(y) { 
     return x+y; 
    }; 
} 

Answer 8

Se una funzione non è comprensibile senza un nome, il nome è probabilmente troppo lungo. Usa i commenti per spiegare il codice criptico, non fare affidamento sui nomi.