Table of Contents |
Books
Aho, Alfred V., Brian W. Kernigan, and Peter J. Weinberger. The AWK Programming Language. Reading, MA: Addison-Wesley Publishing Co., 1988.
Examining the Awk programming language gives you an idea of what C "done right" might be Awk is easy and safe to use, yet has more power than C for many of the common types of text and table processing tools C is often used for. This book is short and easy to follow. Combine it with one of the Awk interpreters or compilers available for the PC, and you'll have a useful tool, as well as a source of ideas for useful C functions and macros.
Cargill, Tom. The Elements of Programming Style. Reading MA: Addison-Wesley Publishing Co., 1992.
Cargill has produced a C++ book in the tradition of The Elements of Programming Style by Kernighan and Plauger. He focuses on programming technique, rather than lexical style, and does a brilliant job. Like Kernighan and Plauger, Cargill starts with previously published program examples and shows their flaws as an introduction to writing correct and comprehensible C++ programs. If you encounter a C++ "expert" who "pooh-poohs" the difficulty of writing robust, reusable C++ classes, push this book in their face Cargill knows better and demonstrates it with examples. Following the book's 58 rules for C++ programming should be a minimum requirement for any C++ programmer.
Coplien, James O. Advanced C++ Programming Styles and Idioms. Reading, MA: Addison-Wesley Publishing Co., 1992.
Don't consider yourself a "master" C++ programmer until you can rightfully claim to understand every chapter in this book. That may take awhile because Coplien has covered a broad range of truly advanced C++ applications. This book is definitely not tutorial, but I still suggest it as an important book for aspiring C++ programmers (and their managers). It's the deepest treatment I've found on applying fundamental software engineering principles to C++ programming. It should provide a healthy "reality check" before anybody goes merrily off to create their own reusable classes. Until a programmer fully understands the first seven chapters of this book (which deal with various object-oriented programming concepts in C++), he or she isn't ready to write production-level, reusable C++ classes to be shared with other programmers. Another thing to be gained from reading Advanced C++ Programming Styles and Idioms is an appreciation for other OOP languages, such as Smalltalk. Coplien describes how to implement the necessary dynamic typing and memory management to give C++ some of the power of languages like Smalltalk; and although Coplien's explanations are clear, the primary lesson is: "Why bother, when other languages already do this gracefully?"
Hamilton, Jennifer. C For RPG Programmers, Loveland, CO: Duke Press, 1992.
Crossing the waters between RPG and C may not be easy, unless you've got a guide who knows the territory well. Hamilton has worked on IBM's RPG/400 compiler and uses her experience with RPG to provide helpful comparisons between the two languages. This unique book is a tremendous resource for RPG programmers who want to learn C, or 3X/400 managers who are evaluating how C might fit in their development toolset. Hamilton's favorable assessment of C provides valuable counterpoints to my more critical assessment of the language.
Horton, Mark R. Portable C Software. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1990.
C is very portable, but transporting C programs opens up a whole new set of traps, many of which are extraordinarily subtle. If you use C to implement software that runs on more than one machine, you should have this book.
Kelly, Al, and Ira Pohl. C by Dissection, second edition. Redwood City, CA: The Benjamin/Cummings Publishing Co., 1992.
C by Dissection might handily win a poll as the "best C tutorial." It earns this wide respect because it teaches C by "dissecting" sample programs so you can learn by example. Each chapter also has short sections on programming style and common programming errors. The second edition covers ANSI C and has a short chapter on C++, which is useful but not really adequate for learning C++. There's also an excellent short introduction to the "make" utility. I only wish the authors would do a larger "make by Dissection" book, too. This is a "must have" for anyone learning C.
Kernighan, Brian W., and Dennis M. Ritchie. The C Programming Language, second edition. Englewood Cliffs, NJ: Prentice Hall, 1988.
A revision of the original C reference and guide (now reflecting the ANSI C standard), this is my favorite source for understanding the formal definition of C. The authors' explanations, while precise, are much more comprehensible than the ANSI or SAA references.
Koenig, Andrew. C Traps and Pitfalls. Reading, MA: Addison-Wesley Publishing Co., 1989.
You must have this book if you program in C. Read it, believe it, and then think about whether you really want to use C.
Ladd, Scott Robert. C++ Techniques & Applications. Redwood City, CA: M&T Books, 1990.
This is a good source of ideas for C++ string implementations. Even if you don't use C++, you can use the concepts to build a standard C function and macro library.
Lafore, Robert. The Waite Group's Microsoft C Programming for the PC, second edition. Indianapolis, IN: Howard W. Sams & Co., 1989.
This is one of the best introductory, tutorial books on C. It is useful even if you use a compiler other than Microsoft C.
Miller, Webb. A Software Tools Sampler. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1987.
This is one of the better advanced C programming texts. The style follows that of Kernighan and Plauger's Software Tools. In his book, Miller also uses the important concept of abstract data types, although his code could be improved. The tools used as examples are handy additions to a C library, and the source code is available on diskette.
Oualline, Steve. C Elements of Style. San Mateo, CA: M&T Publishing, 1992.
If you want a huge headstart on establishing C programming standards, begin with the 113 rules from this book. It's patterned somewhat after the wonderful classic The Elements of Programming Style by Kernighan and Plauger but concentrates more on C lexical style than programming practices. I disagree with a few of the suggestions. For example, Oualline suggests: "When an if affects more than one line, enclose the target in braces." A much easier and safer practice is to always use braces in if statements. But the organization of the book makes it very easy to revise and adapt Oualline's suggestions. Part I of the book discusses the principles underlying the suggested rules. Part II is a concise "Style Manual" that can be quickly accessed for a particular topic. Appendix A is an annotated set of examples and Appendix B is a list of rules by topic. The book also includes short chapters on C++ and on the "make" utility and application directory organization. This is certainly a book every programming manager should have as a starting point for setting up C programming standards.
Ranade, Jay, and Alan Nash. The Elements of C Programming Style. New York, NY: McGraw-Hill, Inc., 1993.
Ranade and Nash copied the title of The Elements of Programming Style by Kernighan and Plauger most closely of any of the C/C++ "style" books, but theirs is least in the spirit or form of the original. Rather than being a discussion of programming principles derived from published examples, this book is a list of several hundred tips accompanied by short "do and don't" examples. Many of their suggestions are sound, some are matters of preference, and some are downright wrong. For example, in one chapter they recommend: "Do not replace C keywords or idioms with macros." But their justification that all C programmers recognize a common set of idioms is unconvincing, especially as C usage expands beyond a small clique of Unix systems programmers. C programmers in the same company should use a standard set of macros (and "helper" functions) across projects and tricky macros should be avoided. But limiting yourself to arcane, primitive forms of C coding whether or not they are "idioms" when simple macros can make coding easier and safer is a foolish restriction. In a later chapter Ranade and Nash even suggest: "Minimize the use of C idioms...replace [them] with a function or macro." Their rationale in this section is "C idioms...are difficult to understand" a much more sensible assessment than their earlier comments. Although I don't think Ranade and Nash have nearly the insight into C programming that some of the other authors listed here do, this is still a good book to scan quickly for C programming tips and additional items to add to your own "C Programming Standards" document. Just don't take their advice as "Gospel."
Schustack, Steve. Variations in C. Redmond, WA: Microsoft Press, 1989.
This isn't the first book to read on C, but it has a few good ideas, including the idea for "visibility" macros. The book also offers a few helpful C style guidelines, including putting a blank after every ( and [ and before every ) and ]. You'd be surprised how much this little tip can improve C readability.
Spuler, David. C++ and C Efficiency. Sydney, Australia: Prentice-Hall of Australia, Ltd., 1992.
As I described in Chapter 6, you can get off course by tricky C programming that's intended to shave a few milliseconds off a program. That doesn't mean you shouldn't know something about performance of C programs, however, and Spuler provides a reasonable guide. He covers both low-level techniques, such as replacing multiplication with addition (a technique which would only be worthwhile inside a loop executed many times), as well as high-level tactics aimed at algorithm improvement. Although the book is a valuable resource, my caution is to draw on its low-level techniques sparingly.
Stroustrup, Bjarne. The C++ Programming Language, second edition. Reading, MA: Addison-Wesley Publishing Co., 1992.
Because Stroustrup knows C++ like nobody else he was the primary designer this is an excellent reference for both the history and the philosophy of C++, as well as the technical details of the language. I find Stroustrup's writing style slow-going at times so I wouldn't recommend this as a tutorial. He does a good job of describing which C++ features are appropriate for certain types of problems, which can help someone new to C++ pick the right techniques.
Microsoft QuickC, Version 2.0 C for Yourself. Redmond, WA: Microsoft Corp., 1988.
Chapter 10, "Programming Pitfalls," includes more than two dozen pitfalls, a number of which are not covered in Koenig's book (C has enough pitfalls for a couple of books).
IBM Manuals
Systems Application Architecture, Common Programming Interface C Reference Level 2 (SC09-1308).
Having read other SAA manuals, I was surprised that the SAA C reference actually shed some light on several C pitfalls. But don't look to it as your primary source for learning C, or even as the first place to turn for an "official" reference. In too many cases, the information is scattered and inconsistent. For example, "linkage" is discussed sometimes as an attribute of a variable (which it is) and at other times as a relationship between two identifiers (which, although it makes more sense for the term "linkage," isn't the way C defines it).
Table of Contents |