Qual è il modo corretto di gestire un percorso globale dei file?

È tipico dei valori dell'hardcode? Sì. La maggior parte del software è scritto in fretta e non lascia mai l'hard disk su cui è compilato, quindi non importa.

Tuttavia, se il suo software che altre persone useranno e installeranno e vorrà essere in grado di configurare dove viene salvato qualcosa, di solito si muove in due modi diversi in base a chi lo sta configurando.

Tuttavia la domanda non riguarda questi scenari. La domanda è se è tipico per i piccoli programmi salvare in un percorso che è memorizzato come variabile globale anziché passare il valore in.

La mia risposta: Sì, è tipico.

Prevedi di voler cambiare il valore di savePath ? Se è così, dovrebbe essere passato come argomento alle tue funzioni. (Anche se le tue funzioni elaborerebbero solo un singolo percorso, potresti volere che il suo valore sia dinamico all'interno del programma.)

Con un nome come savePath potrei prevedere di volerlo cambiare tramite un argomento della riga di comando o di estrarlo da un file di configurazione, pur mantenendo un default hard-coded. In questi casi averlo come costante globale non funzionerebbe.

Personalmente preferisco che le cose siano passate alle mie funzioni in modo che siano autonome dal resto del codice, ma sono io. (Quando passare cose del genere in giro come argomento di funzioni diventa troppo doloroso, puoi usare le monadi di Stato o Reader per aiutare, anche se ciò riduce l'autonomia.)

In Haskell in particolare, puoi avere la tua torta e mangiarla, anche !

changePath2 :: Reader FilePath FilePath
changePath2 = do savePath <- ask
                 -- do stuff with 'savePath'

changePath1 :: FilePath
changePath1 = runReader changePath2 "C:\..."

Per questo banale esempio, ovviamente, potresti facilmente usare una funzione ordinaria piuttosto che Reader , ma usando Reader riduci a molto più complicato lo stile di "iniezione di dipendenza statica" che questo esempio fornisce solo un assaggio di

Se un programma è "piccolo" non importa. Ciò che conta è se il tuo programma è solo uno strumento di gioco o di eliminazione per te stesso o se lo sviluppi per l'ambiente di produzione del tuo datore di lavoro.

Se quest'ultimo è il caso, è probabile che il programma sia alto, anche se inizialmente è "piccolo", può essere utilizzato per diversi anni e ci sarà un'alta probabilità che debba essere adattato alle mutevoli esigenze. Quest'ultimo significa che prima o poi ci sarà bisogno di test unitari o test di regressione. E le funzioni che dipendono dalle variabili globali sono intrinsecamente difficili da testare rispetto alle funzioni pure, che dovrebbero rendere chiara la decisione.