Created at: 2024-07-20
I've been meaning to read other books from Kernighan for a while after reading K&R's C programming book and "Unix a Memoir". The rational is simple: I like his direct and simple writing and he has worked with some very important historical figures in computer science. Also Rob Pike, who co-authored this book, is known for his work on the Go language, and before that, for working at Bell Labs.
This book is relatively old (1999), but I had a sense that much of the advice would still be relevant. That was correct. I would put this book in the "Classics" category of Computer Science for sure.
This is the last page of the book, which summarises the advice:
The following is a list of highlights from the book that I'll likely reference again:
Much information comes from context and scope; the broader the scope of a
variable, the more information should be conveyed by its name.
Use descriptive names for globals, short names for locals. Global variables,
by definition, can crop up anywhere in a program, so they need names long
enough shorter names suffice for local variables; within a function, n may be
sufficient, npoints is fine, and numberOfPoints is overkill.
Use active names for functions. Function names should be based on active
verbs, perhaps followed by nouns: Functions that return a boolean (true or
false) value should be named so that the return value is unambiguous.
Conditional expressions that include negations are always hard to understand
Use the natural form for expressions. Write expressions as you might speak
them aloud. Conditional expressions that include negations are always hard to
understand
Even parenthesizing the macro properly does not address the multiple
evaluation problem. If an operation is expensive or common enough to be
wrapped up, use a function.
Define numbers as constants, not macros. C programmers have traditionally
used #define to manage magic number values.
And macros are a dangerous way to program because they change the lexical
structure of the program underfoot. Let the language proper do the work. In C
and C++, integer constants can be defined with an enum statement, C also has
const values but they cannot be used as array bounds, so the enum statement
remains the method of choice in C.
For similar reasons, sizeof(array[0]) may be better than sizeof(int) because
it’s one less thing to change if the type of the array changes.
Sizes of data types. The sizes of basic data types in C and C++ are not
defined; other than the basic rules that sizeof(char) ≤ sizeof(short) ≤
sizeof(int) ≤ sizeof(long)
In C and C++, a parameter that is an array of strings can be declared as char
*array[] or char **array. Although these forms are equivalent, the first
makes it clearer how the parameter will be used.
The return value of realloc does not need to be cast to its final type
because C promotes the void* automatically. But C++ does not; there the cast
is required. One can argue about whether it is safer to cast (cleanliness,
honesty) or not to cast (the cast can hide genuine errors). We chose to cast
because it makes the program legal in both C and C++; the price is less
error-checking from the C compiler, but that is offset by the extra checking
available from using two compilers.
This is a pervasive and growing concern in software: as libraries,
interfaces, and tools become more complicated, they become less understood
and less controllable. When everything works, rich programming environments
can be very productive, but when they fail, there is little recourse. Indeed,
we may not even realize that something is wrong if the problems involve
performance or subtle logic errors.
Without these principles, the result is often the sort of haphazard
interfaces that frustrate and impede programmers every day.
Avoid global variables; wherever possible it is better to pass references to
all data through function arguments.
Free a resource in the same layer that allocated it. One way to control
resource allocation and reclamation is to have the same library, package, or
interface that allocates a resource be responsible for freeing it. Another
way of saying this is that the allocation state of a resource should not
change across the interface. Our CSV libraries read data from files that have
already been opened, so they leave them open when they are done. The caller
of the library needs to close the files.
A few machines allow ints to be stored on odd boundaries, but most demand
that an n-byte primitive data type be stored at an n-byte boundary, for
example that doubles, which are usually 8 bytes long, are stored at addresses
that are multiples of 8. On top of this, the compiler writer may make further
adjustments, such as forcing alignment for performance reasons.
Detect errors at a low level, handle them at a high level. As a general
principle, errors should be detected at as low a level as possible, but
handled at a high level. In most cases, the caller should determine how to
handle an error, not the callee.
Exceptions should not be used for handling expected return values. Reading
from a file will eventually produce an end of file; this should be handled
with a return value, not by an exception.
Exceptions are often overused. Because they distort the flow of control, they
can lead to convoluted constructions that are prone to bugs. It is hardly
exceptional to fail to open a file; generating an exception in this case
strikes us as over-engineering. Exceptions are best reserved for truly
unexpected events, such as file systems filling up or floating-point errors.
One practical book based on hard-won experience is Large-Scale C++ Software
Design by John Lakos (Addison-Wesley, 1996), which discusses how to build and
manage truly large C++ programs. David Hanson’s C Interfaces and
Implementations (Addison-Wesley, 1997) is a good treatment for C programs.
Read before typing. One effective but under-appreciated debugging technique
is to read the code very carefully and think about it for a while without
making changes. There’s a powerful urge to get to the keyboard and start
modifying the program to see if the bug goes away.
The char type in C and C++ may be signed or unsigned, and need not even have
exactly 8 bits. Leaving such issues up to the compiler writer may allow more
efficient implementations and avoid restricting the hardware the language
will run on, at the risk of making life harder for programmers.
Brand new features such as // comments and complex in C, or features specific
to one architecture such as the keywords near and far, are guaranteed to
cause trouble. If a feature is so unusual or unclear that to understand it
you need to consult a “language lawyer”—an expert in reading language
definitions—don’t use it.
Signedness of char. In C and C++, it is not specified whether the char data
type is signed or unsigned. This can lead to trouble when combining chars and
ints, such as in code that calls the int-valued routine getchar().
Even if char is signed, however, the code isn’t correct. The comparison will
succeed at EOF, but a valid input byte of 0xFF will look just like EOF and
terminate the loop prematurely. So regardless of the sign of char, you must
always store the return value of getchar in an int for comparison with EOF.
Don’t use side effects except for a very few idiomatic constructions like
a[i++] = 0;
Don’t compare a char to EOF. Always use sizeof to compute the size of types
and objects. Never right shift a signed value. Make sure the data type is big
enough for the range of values you are storing in it.
regular if statement with a constant condition may work just as well (as
ifdef): enum { DEBUG = 0 };
if (DEBUG) {
printf(...);
}
If DEBUG is zero, most compilers won’t generate any code for this, but they
will check the syntax of the excluded code. An #ifdef, by contrast, can
conceal syntax errors that will prevent compilation if the #ifdef is later
enabled.
There is one continuing irritation with exchanging text: PC systems use a
carriage return '\r' and a newline or line-feed '\n' to terminate each line,
while Unix systems use only newline. The carriage return is an artifact of an
ancient device called a Teletype that had a carriage-return (CR) operation to
return the typing mechanism to the beginning of a line, and a separate
line-feed operation (LF) to advance it to the next line.
It is not safe to write an int (or short or long) from one computer and read
it as an int on another computer. For example, if the source computer writes
with fread(&x, sizeof(x), 1, stdin); the value of x will not be preserved if
the machines have different byte orders. If x starts as 0x1000 it may arrive
as 0x0010.