9 Style
This chapter covers
- Writing readable code
- Formatting code
- Naming identifiers
Programs serve a dual purpose. First, as we have already seen, they serve to give instructions to the compiler and the final executable. But equally important, they document the intended behavior of a system for the people (users, customers, maintainers, lawyers, and so on) who have to deal with it. Therefore, we have a prime directive.
The difficulty with that directive is knowing what constitutes “readable.” Not all experienced C programmers agree, so we will begin by trying to establish a minimal list of necessities. The first thing we must have in mind when discussing the human condition is that it is constrained by two major factors: physical ability and cultural baggage.
L.T. et al. (1996.), the coding style for the Linux kernel, is a good example that insists on that aspect and certainly is worth a detour if you haven’t read it yet. Its main assumptions are still valid: a programming text has to be represented in a relatively small “window” (be it a console or a graphical editor) that consists of roughly 30 lines of 80 columns, making a “surface” of 2,400 characters. Everything that doesn’t fit has to be memorized. For example, our very first program in listing 1.1 fits into these constraints.