Libraries

I don't have the energy to write a lot, and it wouldn't come out how I want anyway, so I'm going to try something new: I'm just going to post an outline.

Don't write a feature, write a library.
Why?

• Libraries are easy to document. Features are hard to document.
• Libraries lend themselves to test cases.
• Libraries are synonymous with code reuse which will be helpful later
• Libraries force you to think about everything you might want to do later and not just what you need to do now. Also, they force you to define what you will never want to do.
• Libraries have a clear division between interface and implementation. A program designed as a colleciton of libraries is more modular and easier to maintain.

Less API is better.

Have a six-function API. Everything that most people would want to do should be possible (and natural) with no more than six API functions.

The more functions are needed to do simple things, the less useful your library is.

Design the API first. Write the library to match it. This keeps implementation details from bubbling up into the API.

Make (and maintain) a minimal sample program. Anything that will shorten and simplify this program is good. Anything that will add accidental complexity to this program is bad.

Dependencies are bad. Try to make your library easy to install. Reduce any barriers to installing it, and you'll also reduce possible incompatibilities later.

Rude libraries mandate a program structure. Polite libraries fit with any structure. OpenGL is a rude library. Swing is a rude library (by necessity). JDBC and iostream are both polite.

Structures to avoid:

• Event loops. EVENT LOOPS!
• "Listeners". Event handlers should be functions, not objects.

Good structures:

• Fire-and-forget threads. Don't make the user process your events for you.
• Higher-order functions. If you need the client program to pass code in, let it run in their scope.
• Declarative programming.

When in doubt, think about what MFC would do, and do the opposite.