Those .config files can be magic box. You know that it needs to be there and that your project won't work if it's missing or damaged. One of the scariest things for a newbie and sometimes even experienced developers is messing with the .config files.
For starters, it would help to know exactly a .config file is. Like you can probably guess, config is short for configuration. These files hold any initial settings or parameters that your project is going to need to get started. An example of a setting in a web.config file could be how you handle the routing within your project. You might do that by using a rewrite line.
What makes .config files put developers on edge is the fact that one mess up in the config file can cause a project to come tumbling down. Not like you can't go back and undo your changes, but it could happen at one of those critical moments when you can't think of what you did.
You always want to know what you're doing when it comes to your code, although in the case of config files you need to know what you're doing. Right now there isn't a super strict way of writing config files. You could have some written with JSON, XML, YAML, or a combination. It just depends on how your project is setup.
Another thing you have to know about config files is that some programs only load config files when they start and others check the config files periodically. Knowing how the config files will be used will help you figure out how to work with them better and help optimize your project.
Having the right settings and parameters at the start of your project is the only way it's going to run successfully. So make sure you know what you're doing before you go changing things in your config files. They will literally make or break a project.
Have any of you guys done advanced work with config files? I've started digging around in them and they're weird right now.
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (1)
Yes I have done some advanced stuff with config filese, for example having a global and one or more local (user, group or department specific) configuration files. The application would search for the local files at different locations in a specific order. Depending on the type of configuration option, the local settings would either override the global ones or not.
Don't do this unless it is absolutely required. If you have any doubt, ask your customer if it is really needed. Complicated configuration rules can make testing, operations and support extremely difficult.
If you have to do it, add some verbose logging to your software that tells you exactly what value a setting has and where it comes fom, like:
Another recommendation, for more or less the same reasons: Don't make everything configurable. Keep the number of settings small. There is nothing wrong with hardcoding some stuff as long as you define these constants at only one place in your code.