Chapter 9 is a short chapter about the rule of representation
(fold knowledge into data, so program logic can be stupid and robust).

The chapter can be summarized by its final paragraph:

Quote:Do as little work as possible. Let the data shape the code. Lean on your tools. Separate mechanism from policy. Expert Unix programmers tend to see possibilities like these quickly and automatically. Constructive laziness is one of the cardinal virtues of the master programmer.

Chapter 10 is about configuration, in particular startup-environment queries, that is, configuration read from the environment at program initialization.

Some of my programs are configurable, so I will share my experience and thoughts on them on this topic.

The chapter begins stating what should (not) be configurable.
• Do not provide configuration for what can be detected at runtime.
• Do not provide configuration for optimization.
• Do not provide configuration for what can be done with other programs (via a pipeline, for example).
• Consider not providing configuration for cosmetic interface features.
• Consider not providing configuration that can be integrated in the program's normal behavior in an innocuous way that would make the option unnecessary.
• Consider not providing configuration.

On the first and second items, xmenu provides a optimization option switch (-i) to disable image cache initialization when the user is not using icons and then start up faster.
In fact, I could detect whether a icon is specified in the input and, if it is, initialize the image cache; and if no icon is being specified, do not initialize the cache and then run faster.
I'll remove the -i option. It is an optimization option that can be detected at runtime.

After xmenu got popular, I have been including several features users are asking for. And not implementing features is hard.

Also, proliferating options leads to a more complex test coverage.

Quote:Unless it is done very carefully, the addition of an on/off configuration option can lead to a need to double the amount of testing. Since in practice one never does double the amount of testing, the practical effect is to reduce the amount of testing that any given configuration receives. Ten options leads to 1024 times as much testing, and pretty soon you are talking real reliability problems.

The chapter then explains where configuration should be read from.
• Run-control files (in /etc and dotfiles in ~/).
• Environment variables.
• Argument options.

xmenu also reads from X-specific environment variables, the X resources.

Quote:When thinking about which mechanism to use to pass configuration data to a program, bear in mind that good Unix practice demands using whichever one most closely matches the expected lifetime of the preference. Thus: for preferences which are very likely to change between invocations, use command-line switches. For preferences which change seldom, but that should be under individual user control, use a run-control file in the user's home directory.

I had that inside when writing xprompt. Font, color and interface options do not change between invocations, so I read them only via X resources. The prompt mode (argument mode (-a) and password mode (-p)) are more likely to change between invocations, so I read them only via command line options.

In special, I tend to avoid the first configuration source (run-control files). They require implementing a parser and are only necessary for complex option systems; if the program option system needs only a couple on/off switches and a few values, environment variables (or X resources) should be used.