What's the proper way of dealing with a global file path?

Question

I don't have compilable code, because the code in question depends on a large function that's irrelevant to the question, but say I have the following scenario:

savePath = "C:\\..."

changePath1, changePath2 :: String -> String

changePath1 passedPath =
    'Do something with passedPath'

changePath2 =
    'Do something with savePath'

let newPath1 = changePath1 savePath in ...
let newPath2 = changePath2 in ...

Is it more proper to set up functions like changePath1 (where the global path is passed in), or changePath2 (where it just internally uses the global path) If the functions had a chance of processing more then 1 path, obviously I'd use changePath1, but in my current program, there is only 1 path to deal with, so it seems simpler to just have all the functions internally know the global path instead of constantly passing it in.

Thank you

Answer 1

Is it typical to hardcode values? Yes. Most software is hastily written and never leaves the harddrive it is compiled on, so it doesn't matter.

However, if its software that other people are going to use and install, and you want to be able to configure where something is saved, it usually goes two different ways based on who is configuring it.

However the question isn't about these scenarios. The question is if it is typical for small programs to save to a path that is stored as a global variable as opposed to passing the value in.

My answer: Yes it is typical.

Answer 2

Do you foresee ever wanting to change the value of savePath? If so, it should be passed in as an argument to your functions. (Even though your functions would all only process a single path, you might want its value to be dynamic within the program.)

With a name like savePath I could foresee wanting to change that via a command-line argument or pulling it in from a configuration file -- while keeping a hard-coded default. In these cases having it as a global constant wouldn't work.

Personally I prefer to have things like that passed to my functions so that they're autonomous from the rest of the code, but that's me. (When passing things like that around as an argument to functions becomes too painful, you can employ the State or Reader monads to help, though that cuts down on the autonomy.)

Answer 3

In Haskell in particular, you can have your cake and eat it, too!

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

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

For this trivial example, of course, you could just as easily use an ordinary function rather than Reader, but using Reader scales up to much more complicated "static dependecy injection"-style things that this example only gives a glimpse of.

Answer 4

If a program is "small" does not matter. What matters is if your program is just a game or throwaway tool for yourself, or if you develop this for the production environment of your employer.

If the latter is the case, chances are high the program, even if it is initially "small", may be used for several years, and there will be a high chance that it has to be adapted to changing requirements. The latter means that sooner or later there will be a need for unit tests or regression tests. And functions which depend on global variables are inherently harder to test than pure functions, which should make the decision clear.