> therefore, you will be externalizing these values and decouple them from the application, which will give you great flexibility in the long term I think this

> therefore, you will be externalizing these values and decouple them from the application, which will give you great flexibility in the long term I think this is one of the worst "Best Practices" ideas that are parroted by people who haven't thought deeply about the issue. It's really a bad legacy from the era when most software was actually distributed. Now that most software runs in environments that are controlled by the same organization that developed the software, the principle is far less valuable. Nowadays, most software should have most of its configuration information - paths, DB URLs, HTTP endpoints, etc - hard-coded into it. This strategy follows the "convention over configuration" philosophy, and it gives you a range of benefits. First of all, you can run tests on your config to make sure everything is working properly (check various files are present, do a SELECT * LIMIT 1 from DB tables, etc). You can catch config errors at compile time, eg by using enums like prod/dev/qa to represent environment names. And it prompts you to apply a refactoring mindset to your config - when you notice that your config code is repeating itself extensively, you'll realize this and be able to take steps to refactor, standardize, and simplify the config.