The Art of Unix Programming

haoji

Threads 鈥

haoji

Macros 鈥

haoji

The cantrip pattern
The emitter pattern
The absorber pattern
The compiler pattern
The ed pattern
The rogue pattern
The 鈥榮eparated engine and interface鈥

haoji

Chapter 4. Modularity

Prev Part II. Design

Next



Chapter 4. Modularity

Keeping It Clean, Keeping It Simple

Table of Contents

Encapsulation and optimal module size
Compactness and orthogonality
Compactness
Orthogonality
The DRY rule
The value of detachment



Top-down, bottom-up, and glue layers
Case study: C considered as thin glue



Library layering
Case study: GIMP plugins



Unix and object-oriented languages
Coding for modularity


There are two ways of constructing a software design. One is to make it so simple that there
are obviously no deficiencies; the other is to make it so complicated that there are no
obvious deficiencies. The first method is far more difficult.

--C. A. R. Hoare

The early developers of Unix were among the pioneers in software modularity. Before them,
the Rule of Modularity was computer-science theory but not engineering practice. It bears
ampification here: The only way to write complex software that won't fall on its face is to
build it out of simple modules connected by well-defined interfaces, so that most problems
are local and you can have some hope of fixing or optimizing a part without breaking the
whole.

haoji

The tradition of being careful about modularity and of paying close attention to issues like
orthogonality and compactness is still much deeper in the bone among Unix programmers
than elsewhere.

There is a natural hierarchy of code-partitioning methods that have evolved as programmers
have had to manage ever-increasing levels of complexity. In the the beginning, everything
was one big lump of machine code. The earliest procedural languages brought in the notion
of partition by subroutine. Then we invented service libraries to share common utility
functions among multiple programs. Next, we invented separated address spaces and
communicating processes. Today we routinely distribute program systems across multiple
hosts separated by thousands of miles of network cable.

All programmers today, Unix natives or not, are taught to modularize at the subroutine level
within programs. Some learn the art of doing this at the module or abstract-data-type level
and call that 鈥榞ood design鈥

haoji

Encapsulation and optimal module size

Prev Chapter 4. Modularity

Next



Encapsulation and optimal module size

The first and most important quality of modular code is encapsulation. Encapsulated
modules don't expose their internals to each other. They don't call into the middle of each
others' implementations, and they don't promiscuously share global data. They communicate
using application programming interfaces (APIs) 鈥

haoji

defect density curve) after which it goes up as the square of the number of the lines of code
(which is what one might intuitively expect for the whole curve, following Brooks's Law).

Figure 4.1. Qualitative plot of defect count and density vs. module size.



This unexpectedly high incidence of bugs at small module sizes is robust across a wide
variety of systems implemented in different languages. Hatton has proposed a model relating
this nonlinearity to the chunk size of human short-term memory. [16]

In non-mathematical terms, this means there appears to be a sweet spot between 200 and 400
logical lines of code that minimizes probable defect density, all other factors (such as
programmer skill) being equal. This size is independent of the language being used 鈥

haoji

Compactness and orthogonality

Prev Chapter 4. Modularity

Next



Compactness and orthogonality

Code is not the only sort of thing with an optimal chunk size. Languages and APIs (such as
sets of library or system calls) run up against the same sorts of human cognitive constraints
that produce Hatton's U-curve.

Accordingly, there are two properties that Unix programmers have learned to think very hard
about when designing APIs, command sets, protocols, and other ways to make computers do
tricks. These are compactness and orthogonality.

Compactness

Compactness is the property that a design can fit inside a human being's head. A good
practical test for compactness is this: does an experienced user normally need a manual? If
not, then the design (or at least the subset of it that covers normal use) is compact.

Compact software tools have all the virtues of physical tools that fit well in the hand. They
feel pleasant to use, they don't obtrude themselves between your mind and your work, they
make you more productive 鈥

haoji

calls sufficient for most applications programming (filesystem operations, signals, and
process control) in their heads, the C library on modern Unixes includes many hundreds of
entry points for, e.g. mathematical functions, that won't all fit inside a single programmer's
cranium.

Among Unix tools, make(1) is compact; autoconf(1) and automake(1) are not. Among
markup languages, HTML is compact, but DocBook (a documentation markup language we
shall discuss in Chapter 16 (Documentation)) is not. Man-page macros are compact, but
troff(1) markup is not.

Among general-purpose programming languages, C and Python are compact; C++, Perl,
Java, Emacs Lisp, and shell are not (especially since serious shell programming requires you
to know half-a dozen other tools like sed(1) and awk(1)).

Some designs that are not compact have enough internal redundancy of features that
individual programmers end up carving out compact dialects sufficient for that 85% of
common tasks by choosing a working subset of the language. Perl is like this, for example.
Such designs have a built-in trap; when two programmers try to communicate about a
project, they may find that differences in their working subsets are a significant barrier to
understanding and modifying the code.

Non-compact designs are not automatically doomed or bad, however. Some problem
domains are simply too complex for a compact design to span them. Sometimes it's
necessary to trade away compactness for some other virtue, like raw power and range. Troff
markup is a good example of this. So is the BSD sockets API. The purpose of emphasizing
compactness as a virtue is not to teach the reader to treat compactness as an absolute
requirement, but to do what Unix programmers do 鈥

haoji

contrast level, and (if the monitor has one) the color balance control will be independent of
both. Imagine how much more difficult it would be to adjust a monitor on which the
brightness knob affected the color balance 鈥