It’s generally recommended to avoid hardcoding when you build a piece of software, but some programmers have gone extreme in this direction that they try to avoid hardcoding at all costs, even if the cost of hardcoding is actually smaller than the cost of their alternative. I think it’s safe to say that some programmers started using XML as a programming language!
I was moved to work on a different project within the team, a project I am looking at for the first time and one thing that caught my attention is a 500-lines XML file that is supposed to hold the project’s configuration, but is it? When I dived into the details of this confusing config file I started thinking what went wrong in this project that caused a config file to grow like that. What I concluded is that this XML file doesn’t only contain configuration; it contains program logic as well! You might think: how can an XML file contain program logic?! Simply, by making your program very configurable and putting all that configuration in the XML file you’ll be able to control your program’s logic from that XML file. This is a bad practice for several reasons:
- It makes the config file confusing for the user, or for the person responsible for deployment in case of web apps.
- A problem in the configuration is harder to trace than a problem in the code.
- Configuration errors are not detectable by compilers.
So, how do we determine what should go in a config file and what should go in code? There isn’t any solid rules to follow, but here are some helpful guidelines that I can think of:
- If a config value is not to be modified by an end user or a deployment engineer then it should probably go in the code. If you must, make it a code configuration using const variables for example.
- If a config change request has to be assigned to a developer then take that value out of the config file.
- If your config file becomes large or hard to understand then you are probably doing something wrong.
- If throughout the life cycle of your project you get more config issues than code issues you are definitly doing something wrong. So try to clean up your config.
- Make sure the host is the only one that accesses the config file. By host, I mean your main program. In other words, if you have a component referenced by an application, that component should not have direct access to the config, instead, it should expect its config values to be passed over from the main program through function arguments. This reduces the possibility of bugs by allowing the compiler to detect changes in an external component’s configuration. For example, if a change to the external component introduced a new config value, your compiler will immediately notify you of a missing parameter.
- Don’t make your configuration configurable! Yes, I have seen that before so don’t be surprised. I have seen situations where the key of a config entry is determined by another configuration!
It’s usefull to always remember that XML, or any conceptually similar file format, is not a programming language. It’s not debuggable, it’s not compilable, it’s not traceable, it’s not sequential, it doesn’t even have an entry point. A programming language’s code on the other hand is easily traceable and you have tons of tools that can help you deal with it, so use it unless you absolutely have to put that parameter in a config file. Think of it this way, if your config values are not to be modified after you build then the only difference between a config file and a C++ file with hardcoded set statements is that the latter is harder to go wrong!