Re: [dev] saving program options

On Sun 24 Jan 2010 at 11:57:34 PST anonymous wrote:
>Where programs should store their options? Sometimes it is said that
>global variables are bad, but what is better? Some huge structure
>storing all options? Of course, they can be divided into many
>structures or they can be passed on a stack instead of passing pointer
>to structure but it is not effective.
>
>Here is citation from TAOUP
>(http://www.catb.org/esr/writings/taoup/html/ch04s06.html):
>"
>Here are some questions to ask about any code you work on that might
>help you improve its modularity:
>
> * How many global variables does it have? Global variables are
> modularity poison, an easy way for components to leak information
> to each other in careless and promiscuous ways.
> * Do any of your APIs have more than seven entry points? Do any of
> your classes have more than seven methods each? Do your data
> structures have more than seven members?
>"
>
>So lots of global variables are bad, but saving them in a local
>structure is bad too? Is there any other other solution?

TAOUP also recommends small programs that do just one thing. If you
have so many options that you need a "huge structure" to store them,
that might be a sign that your program is overly complex. Consider
factoring it into a set of smaller cooperating processes.

Many people have become accustomed to thinking in terms of large,
monolithic applications. This leads them to think of modularity as
something that only applies to the functions within that kind of
application.

Instead, think of the *shell* as the main program and your set of small
utilities as the modules. The classic Unix utility designed to do one
thing and do it well is the paradigm example of what we mean by
coherence. The operating system enforces encapsulation. When the
modules communicate with each other using text streams over stdin and
stdout, or using sockets and text-based protocols like those described
in TAOUP, then they will be loosely coupled. These are the virtues
which are usually associated with good "modularity".

Take those rules of thumb like the ones you cite above and apply them to
the programs themselves. A program that takes a lot of options is like
a function that takes a lot of arguments.
Received on Sun Jan 24 2010 - 21:46:03 UTC