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.
