Tag Info

New answers tagged

3

Config files should almost be the last places to put business rules or parameters. Config files should in general used only for administrative functions - things that DB admin or IT admin would control - certainly not the business logic. One of the key reasons why config files for business logic is bad is because typically business rules not only change in ...


0

Like @theatlasroom mentioned use some technique to structure your config-parameters. When that is in place, and since the parameters are "sensible to change" you might consider building some interface for editing them. Having one, it can guard against unreasonable or harmful values (some times entered by mistake) giving the user guidance.


2

YAML, JSON or XML are often used in frameworks for managing config settings. Depending on the language you are using, another option can be to use a structured entity (ie in a OO language using a class) to hold your config settings.


0

It's a BAD PRACTICE. A basic principle of software design: Don't hard-code configuration values inside your programs. This is especially true for anything that has a reasonable chance of changing in the future. The program code that you develop should be the same code that goes into any environment such as QA testing, UAT, and production. If somebody ...


1

What if I want to run the backend on my own machine but not on port 55793, for example if I were running multiple versions at the same time to compare them? What if I want to run the application backend on one machine, but access it from another? What if I want to add a fourth environment? As others have pointed out, you have to recompile just to change the ...


4

For one, (as others have mentioned) this is a bad idea because you're tying implementation details into your code. This makes it difficult to change things. As mentioned in this answer, if you want to add a new environment now you have to update your code everywhere, instead of just adding your program to a new environment. There is another serious flaw ...


13

You are absolutely right in thinking this is a bad practice. I've seen this in production code, and it always comes back to bite you. What happens when you want to add another environment? Or change your development server? Or you need to fail over to a different location? You can't because your configuration is directly tied to code. Configuration should ...


80

Code that works for you and is easy to maintain is by definition "good". You should never change things just for the sake of obeying someone's idea of "good practice" if that person cannot point out what the problem with your code is. In this case, the most obvious problem is that resources are hard-coded into your application - even if they're selected ...



Top 50 recent answers are included