Usa "etichette" o "flet" annidato?

4

Ho una gerarchia di funzioni, molte funzioni sono chiamate da una singola funzione.

Ci sono tre opzioni:

  • Utilizza defun : cioè tutte le funzioni sono globali anche quelle che sono intesi solo per uso interno da una singola funzione. Utilizza un pacchetto per esportare le funzioni che i client dovrebbero chiamare.
  • Utilizza labels in modo che le funzioni abbiano scope lessicale e siano libere di chiamare qualsiasi altra funzione all'interno di labels .
  • Usa nidificato flet in modo che ogni funzione possa accedere alle funzioni di cui ha bisogno.

C'è un modo migliore per farlo? Se sì, cos'è?
Quali sono le considerazioni che dovrei riflettere?

NOTA: sto imparando le domande , quindi mi interessa il 'modo giusto' ™ e meno nel forse più pragmatico basta scriverlo come preferisci e non pensarci troppo.

    
posta Kasper van den Berg 28.12.2017 - 23:35
fonte

1 risposta

3

Generalmente il Lisp è meno dogmatico sullo stile di programmazione. Alcuni stili di programmazione potrebbero non essere desiderabili nel codice scritto a mano, ma potrebbero essere utili per il codice generato. Poiché il codice generato (- > macros) è popolare e ben supportato in Lisp, i programmi possono generare codice abbastanza complesso.

Processo di sviluppo con refactoring

Spesso scrivere codice è un processo evolutivo con qualche refactoring. Una cosa che ho fatto a volte è questa:

  1. scrivere una funzione lunga e complessa
  2. identifica la necessità di documentare parti del codice
  3. invece della documentazione convenzionale - > estrae parti del codice in funzioni locali con nome con arglist. Il nome rende chiaro lo scopo e l'arglist è l'interfaccia
  4. se queste funzioni locali sembrano generalmente utili e saranno riutilizzate - > estraili in funzioni globali - > documentali e / o esportali

Possiamo pensare a vari argomenti per determinati stili:

(i seguenti elenchi molto probabilmente non sono completi)

Funzioni globali piane in un pacchetto, dove vengono esportati solo i relativi e le funzioni local / helper probabilmente non vengono esportate e / o denominate appositamente.

Negativo

  • probabilmente molti nomi in un pacchetto
  • elenchi di argomenti possibilmente più complessi da passare in tutto il necessario
  • è necessario mantenerli locali in un pacchetto, possibilmente con una convenzione di denominazione speciale
  • la struttura del codice potrebbe essere più difficile da riconoscere, poiché le dipendenze non sono visibili in base all'ambito lessicale

Positivo

  • forse più indipendente
  • testare le singole funzioni potrebbe essere più semplice
  • facile tracciamento / passaggio delle singole funzioni
  • probabilmente più facile da documentare

non chiara

  • impatto sulle prestazioni poco chiaro

Funzione globale con più funzioni locali organizzate in qualche ambito lessicale

Positivo

  • variabili in ambito possono essere condivise - > porta a più brevi arlists
  • Le dipendenze
  • sono meglio visibili a causa della gerarchia degli ambiti lessicali
  • le funzioni locali non possono essere utilizzate al di fuori dell'ambito previsto - > nascondere le informazioni
  • Le funzioni
  • potrebbero essere più facili da capire nel contesto

Negativo

    Il codice
  • diventa più gerarchico - > sembra più complesso - > possibilità di nuovi errori
  • strumenti potrebbero non essere in grado di tracciare o gestire funzioni locali - > ha bisogno di un Lisp con supporto per questo quando questi strumenti potrebbero essere necessari
  • la funzione globale può diventare lunga
  • forse più difficile da testare
  • lo smontaggio diventa lungo, quando si guarda il codice macchina
  • la documentazione
  • rende il codice ancora più lungo
  • livelli di rientro profondi (er)
  • la localizzazione basata su strumenti del codice sorgente per una funzione locale potrebbe essere più difficile
risposta data 30.12.2017 - 17:03
fonte

Leggi altre domande sui tag