I first started programming C in high school. Most of what I learned was from a book I bought myself. The class itself wasn’t very good. The book I had on C didn’t teach me everything a beginning programmer needs to know.Knowledge of good coding style was something I lacked. Without any examples of good style in source code I developed an odd style that used really complex for statements. They made sense to me at one point but after I had written them they were both hard to debug and hard to read. I didn’t improve until I started learning programming again several years later.
My dad and the book Code Complete taught me practically everything I know about style and debugging. How Not to Program in C++ by Steve Qualline is a book with a theme similar to Code Complete. It has many examples of how not to program and programming practices that are just bad.
I enjoyed reading How Not to Program in C++ and think that it would have helped me when I was less experienced. The book is made up of many small examples which make it easy to read periodically. Reading it would be a good way to spend small bit of extra time. Most technical books are not suited for that.
Small programs featuring bugs is what the book contains. Most are one page long. Introductory text explains a little about the program. After that is line numbered source code featuring real live programming bugs. After the code are page numbers for hints and the solution. Many of the programs have a random joke or anecdote after the source code.
I thought the author’s sense of humor was very much like my own. The jokes were a combinations of random style humor and programmer humor. Some pages just had one sentence like “This page isn’t intentionally left blank.” While other pages had programmer humor like
“Shakespeare has given us the age-old question, “To be or not to be?” Computer science has given us the answer: “FF”.
“0x2B | ~0x2B == 0xFF”
One of the versions of hello world uses fork. That is humor.
Reading through one of programs in the book involves a few steps. First step is to read the introduction and title for a clue to the nature of the program and bug. The title is often a joke based on the bug. A program with the title “No Comment” likely has problem involving comments. The second step is reading the source code and looking for a problem. The problem might be silly mistake or it might be mistake in the logic. It’s often something silly which reminds me of my own code. The last step is to read hints and the solution. The solution often gives a recommendation of how to avoid the problem by using a different style of programming.
Many different bugs are covered. Most of them fall into the syntax error, misuse of a common function, and misuse of a language feature categories. I felt they were well chosen as they were mistakes I remember making. Usually I would be able to quickly guess the bug the source code would have based on what functions and language features the code used.
I only had a few problems with the content of book. Some of the bugs seemed trivial. Some of the solutions had to do with text output getting formatted wrong. I figured out how to format text pretty quickly when I first started programming. Sometimes I expected one of the chapters to have more complex bugs. The threaded bugs in chapter 11 were quite simple. The expert bugs in chapter 8 were more obscure then they were complex. I wanted bugs that were complex to the point that I would feel that I would never solve them without looking at the solution.
Besides the nice feeling I got quickly solving some of the simpler bugs I enjoyed the embedded programming bugs in chapter 11 the most. They featured problems that were not familiar to me since I’ve never done any embedded programming. They mostly dealt with keeping the compiler from optimizing out code that’s only purpose was kill time before accessing hardware.
The majority of the source code is cross platform and uses libraries and system calls found on most operating systems. There is a little use of POSIX libraries also. It is mostly C++ code with a little regular C.
I think this book would be the most useful for somebody that has just learned the basics of C and C++. It is still a fun book for any programmer who enjoys solving bugs but is more useful for someone less experienced. The problems are more examples of things not to do then hard problems that would challenge an experienced programmer. I don’t think this is bad thing. It just limits who will get the most enjoyment and knowledge out of the book.
About the Author:
Corey Holcomb-Hockin is a programming, open source, and game design enthusiast. When I’m not trying to get my writing published on OSNews I’m designing a RPG in Blades of Avernum or watching programs compile on FreeBSD. I live in Otis Orchards, Washington.