A few years ago I created xcop, a simple command line tool that can check the style of an XML file. It’s similar to Checkstyle (for Java) and Pep8 (for Python), but for XML. It’s pretty easy to use xcop: just run it with a few command line arguments and it returns the list of errors found in your XML file, if there are any. However, some of the arguments may be convenient to have as defaults and instead of passing them through the command line on every execution, we could store them in some configuration file. The question is: What is the best format for this file? YAML, JSON, or TOML? None of them! I suggest plain text.
Let’s say, you want xcop to check all *.xml files in your repository, but ignore XML files in the .idea/ directory. You also want to make sure all XML files have a license in their preamble. This is how you would call xcop:
$ xcop --include '*.xml' --exclude '.idea/**' \
--license LICENSE.txt
You have to use this set of arguments everywhere you call xcop: in the build script, in the CI/CD pipeline, and on your laptop when you check that everything is correct. What some of us sometimes do is create a new Bash file called run_xcop.sh with exactly this single command.
I suggest a better solution. You can create a .xcop plain text file in the root of the repository and put all the required “default” command line options there, one per line:
--include=*.xml
--exclude=.idea/**
--license=LICENSE.txt
Now, you can call the tool just like this:
$ xcop
It will find the .xcop file and will read all lines from it, treating each of them as command line arguments. It will basically concatenate what is provided in the command line with what is found in the file with defaults.
I believe this approach is much better than YAML, JSON, XML, TOML, INI, and other configuration formats simply because it doesn’t require us users to learn two formats: one for command line options, another one for the configuration file. We learn just one and use it interchangeably either when we call the tool “manually” or when we configure its behavior in the file with defaults.
By the way, it’s possible to configure the behavior of xcop globally creating the file ~/.xcop (in the home directory of the user). The defaults from this file will also be concatenated with the ones provided in the command line and with the ones found in the local .xcop file.
I designed a few of my other command line tools using the same principle, including pdd, texqc, and texsc.
