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:
- scrivere una funzione lunga e complessa
- identifica la necessità di documentare parti del codice
- 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
- 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