In the book Pragmatic Programmer, there are several parts advocating putting things in configuration rather than code:
First, we want to make our systems highly configurable. Not just things such as screen colors and prompt text, but deeply ingrained items such as the choice of algorithms, database products, middleware technology, and user-interface style. These items should be implemented as configuration options, not through integration or engineering.
Tip 37: Configure, don't integrate
Tip 38: Put abstractions in code, details in metadata
I feel like, if different end users use different options, then obviously you put it in a configuration file. Because how else are you going to do it? Have them edit the code and recompile?
Consider all the examples: screen colors, prompt text, choice of algorithms, database products, middleware technology, user-interface style. I wouldn't make those properties unless I had to (because people choose different things).
But there must be more cases than that. Otherwise the book wouldn't devote two tips to it.
Advantages I can think of for putting stuff in properties:
Disadvantages I can think of for putting stuff in properties:
When would you choose one over the other?
Mark
I think it's a case based system, where the team has to decide. Sometime it's way easier to decide as a team to just follow a convention and if you got code reviews and a good culture that's a good thing
however as soon as you move outside of your scope of ownership a.k.a libraries I always go for configuration over convention, but always with a working default set with 'expected' default behaviour.
As you mention the problem is the complexity of configuration and the abstraction of configuration. This where I go for domain driven approaches so my model orients towards the user.
For an ops guy I write different configurations than for a dev guy for example. The medium also differs, ini, toml, yml, env based on the application and it's intended users / usecase.
very often I build hook systems that integrate with each other so you have the flexibility of using env variables but you can have a local conf file as well.
It's a usecase debate in my opinion with the main focus: who are the people who use it.
Also if I remember correct in the book there is the point about generative code. If you go for configuration the code should be generated from the configuration / definition.
I'll post the reasons from the book, but I'm not convinced:
I like good design, but I think it can be done without configuration files...
Joseph S Stevens
10 years of Software Development, Husband, Father and Functional Programming enthusiast.
This is too vague a question to get to the bottom of it, the answer isn't Always Code, or Always config, it REALLY depends on the context. Be more specific.