I use both flags and configuration when writing new software, and tried to get my thoughts down on determining when to use each, or in some cases both, but never neither :)

I start a lot of new projects, I'll always find some reason to write a program to make some process easier. Programs, of course, work on input and produce output of some kind. There's input and there's behavior. The behavior is mostly controlled by flags or configuration. Frequently I'm faced with the question: should this option be a flag or configuration?

What I've mostly been lead by in this answer is based on complexity of configuration, and also how willing I am and how easy it is to provide it on the command line. Like if it's a "mode" flag and the options are easy to type, I'll have it be a flag. If it's a connection string to a database, I'm going to throw it in a configuration file. Also there are many many times where I use both flags and a configuration file.

For instance, I wrote a program to generate code based on a definition file. What my program takes in through the flags is the current file name, what directory to write to, and for the code, what namespace to give it. What it takes in configuration file are all of the templates to use, for each type of thing that can be generated. Like SQL Tables, code files, crud stored procedures, etc. These are the same against each file which can be specified on the flag.

I think this approach definitely makes sense in this scenario. I'm not going to provide all of that stuff on the command line as flags, but I'm also not going to be changing a config file for each file I want to work on. A typical project that's using this might have 30 or so files that it needs to work on, that would require 30 config files in addition. That seems silly.

So another determining factor to answer the question of flag vs configuration, flags are definitely for instances of the program running. "For this instance, I want to work on this file" etc. I think that's a pretty good answer. Configurations are for the environment that I'm working on. "In this environment, this is the connection string" or "In this environment, these are the types of files that I want to generate". In that case, this configuration is used across many different subsets of data in the overall application I'm using it in, and since they all use the same configuration, they will be extremely consistent and predictable.

I can't imagine myself passing a connection string or another environment defining variable along the command line as a flag anymore, after getting these thoughts down on paper. Of course, I will still let the ease of setting them determine if I make it a flag, as not every program needs a configuration file. A lot of programs I write just take in a file or folder and some other flags to help it along.

So in terms of priority, if I can make it happen, a program will only have flags to give it input and behavior. If there's a possibility that the flags would lead to some kind of complex syntax parsing which could easily be put into JSON instead, then it'll have configuration. If it has a connection string property, it'll have configuration. I think those are the rules and I'm sticking to them.

The program in question is my CRUDGEON app which I'm firing up again due to new work! Exciting :)