5 ms·
There are other approaches to this as well: 1. Passing around a configuration or context (similar to your gripe around params) 2. Referencing some kind of glo
by d4mi3n 5y ago
There are other approaches to this as well:
1. Passing around a configuration or context (similar to your gripe around params)
2. Referencing some kind of global configuration (a la env vars)
3. Referencing a local or scoped configuration (for example, a method of an object can check instance variables that dictate behavior)
I personally prefer either a passed context or a local configuration; I find both easier to test in isolation. Global contexts have their uses, but tend to become problematic when they clash with other libraries or tools that may also be present in the execution environment.
- kbenson 5y agoThose are good approaches, and I wouldn't try to use manually set env vars for most things. I do tend to think they work very well for debug an dry run options though, because those are generally ephemeral, and things you might want to set ad-hoc in different environments easily without changing the config for everything in that environment, or passing around a special config which may not be updated when the real one is. That said, I'm not married to it, if I saw something that seemed obviously better, I would switch. I also suspect that different languages may make one approach easier/better than others based on their capabilities, idioms, etc. In many scripting languages, accessing an environment variable is extremely easy. In some compiled or more strictly typed languages, the access and conversion to the expected type might be cumbersome enough to do on site that it's worse, and if you are standardizing in come parsing routine, that might tip the benefits in favor of some global context that is used instead.