While surfing on the Net (as the media likes to hype) I ran into a site that had some essays on programming. One, “Notes on Programming in C” by Robert Pike had some interesting points.
Procedure Names
Procedures names should reflect what they do; function names should reflect what they return. Functions are used in expressions, often in things like IF’s, so they need to read appropriately.
IF (CHECKSIZE(x))
is unhelpful because we can’t deduce whether CHECKSIZE returns true on error or non-error, instead:
IF (VALIDSIZE(x))
makes the point clear and makes a future mistake in using the routine less likely.
Complexity
Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.
Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost be self-evident. Data structures, not algorithms, are central to programming.
Programming with Data
Algorithms, or details of algorithms, can often be encoded compactly, efficiently and expressively as data rather than, say, as lots of IF statements. The reason is that the complexity of the job at hand, if it is due to a combination of independent details, can be encoded. A classic example of this is parsing tables, which encode the grammar of a programming language in a form interpretable by a fixed, fairly simple piece of code. Finite state machines are particularly amenable to this form of attack, but almost any program that involves the ‘parsing’ of some abstract sort of input into a sequence of some independent ‘actions’ can be constructed profitably as a data-driven algorithm.
One of the reasons data-driven programs are not common, at least among beginners, is the tyranny of Pascal. Pascal, like its creator, believes firmly in the separation of code and data. It therefore (at least in its original form) has no ability to create initialized data. This flies in the face of the theories of Turing and von Neumann, which define the basic principles of the stored-program computer. Code and data are the same, or at least they can be. How else can you explain how a compiler works?
Function Pointers
Another result of the tyranny of Pascal is that beginners don’t use function pointers. (You can’t have function-valued variables in Pascal.) Using function pointers to encode complexity has some interesting properties.
Some of the complexity is passed to the routine pointed to. The routine must obey some standard protocol – it’s one of a set of routines invoked identically – but beyond that, what it does is its business alone. The complexity is distributed.
There is this idea of a protocol, in that all functions used similarly must behave similarly. This makes for easy documentation, testing, growth and even making the program run distributed over a network – the protocol can be encoded as remote procedure calls.
I argue that clear use of function pointers is the hard of object-oriented programming. Given a set of operations you want to perform on data, and a set of data types you want to respond to those operations, the easiest way to put the program together is with a group of function pointers for each type. This, in a nutshell, defines class and method. The O-O languages give you more of course, – prettier syntax, derives types and so on – but conceptually they provide little extra.
Combining data-driven programs with function pointers leads to an astonishingly expressive way of working, a way that, in my experience, has often lead to pleasant surprises. Even without a special O-O language, you can get 90% of the benefit for no extra work and be more in control of the result. I cannot recommend an implementation style more highly. All the programs I have organized this way have survived comfortably after much development – far better than with less disciplined approaches. Maybe that’s it: the discipline it forces pays off handsomely in the long run.